💾 Archived View for gemini.circumlunar.space › users › kraileth › neunix › eerie › 2018 › exploring_… captured on 2024-08-18 at 18:04:48. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-05)
-=-=-=-=-=-=-
Here I'm republishing an old blog post of mine originally from September 2018. The article has been slightly improved.
While I've been using Unix-like systems for quite a while and heavily for about a decade, I'm completely new to operating systems of the Solaris / illumos family. So this post might be of interest for other *BSD or Linux users who want to take a peek at an illumos distribution - or to the illumos people interested in how accessible their system is for users coming from other *nix operating systems.
In my previous post I wrote about why I wanted to take a look at OmniOSce in the first place. I also detailed the installation process. This post is about the first steps that I took on my newly installed OmniOSce system. There's a lot to discover - more actually than I first thought. For that reason I decided to split what was meant to be one post into two. The first part covers service management and creating a user.
A look beyond the BSD teacup: OmniOSce installation
According to a comment, a Reddit user would be more interested in an installation on real hardware. There are two reasons why I like to try things out using a hypervisor:
1) It's a quick thing to do and no spare hardware is required
2) it's pretty easy to take screenshots for an article like this.
OmniOS booted up and root logged in (PNG)
However I see the point in trying things out on real hardware and I'm always open to suggestions. For that reason I'll be writing a third post about OmniOS after this one - and will install it on real hardware. I've already set a somewhat modern system aside so that I can test if things work with UEFI and so on.
In the default installation I can simply login as _root_ with a blank password. So here we are on a brand new OmniOSce system. What shall we explore first?
Solaris "key creature" logo for Neo²
The installer asked me which keymap to use and I chose German. While I'm familiar with both the DE and US keymaps enough that I can work with them, I've also learned an ergonomic variant called _Neo²_ (think dvorak or colemak on steroids) and strongly prefer that. I've also written about it [unfortunately the English page is no longer available].
Keyboards, layouts and ergonomics (pt. 2) [2015 article]
It's supported by X11 and after a simple _setxkbmap de neo -option_ everything is fine. On the console however... For FreeBSD there's a keymap available, but for illumos-based systems it seems I'm out of luck.
BSD "key creature" logo for Neo²
So here's the plan: Configure the system to let me SSH into it! Then I can use whatever I want on my workstation PC that I connect from. Also this scenario touches upon a nice set of areas: System services, users, network... That should make a nice start.
During the first startup, _smf(5)_ was mentioned so it might be a good idea to look that up. So that's the _service management facility_. But hey, what's that? The manpage clearly does not describe any type of configuration file! And actually the category headline is "Standards, Environments, and Macros"! What's going on here?
First discovery: The manpage sections are different. _Way different_, actually! Sections like man1, man1b, man1c, man3, man3bsm, man3contract, man3pam, etc... Just take a look. Very unfamiliar but obviously clearly arranged.
The smf manpage is also pretty informative and comprehensive including the valuable _see also_ section. The same is true for other pages that I've looked at so far. On the whole this left a good impression on me.
Solaris has replaced the traditional init system with _smf_ and illumos inherited it. It does more than the old init did, though: Services are now _supervised_, too. If a service is meant to be kept running, smf can take care of restarting it, should it die. It could be compared to systemd in some regards, but smf was created earlier (and doesn't have the same ... well, controversial reputation).
Services are described by a *Fault Management Resource Identifier* or _FMRI_ which looks like _svn:/network/loopback:default_ but can be shortened if they are unambiguous. I had no idea how to work with all this but the first "see also" reference was already helpful: _scvs_ can be used to view service states (and thus get an idea about what the system is doing at all).
Another command caught my attention right away, too: _svcadm_ sounded like it might be useful. And indeed this was just what I was searching for! The manpage revealed a really straight-forward syntax, so here we go:
# svcadm enable sshd
svcadm: Pattern 'sshd' doesn't match any instances
# svcadm enable ssh
The latter command did not produce any output. And since we're in Unix territory here, that's just what you want: It's the normal case that something worked as intended, no need for output. Issuing a svcs and grepping for "ssh" shows it now so it should be running. But is SSH really ready now? Let's check:
# sockstat -4 -l
-bash: sockstat: commmand not found
Yes, right, this is not FreeBSD. One _netstat -tulpen_ later I know that it's not exactly like Linux, either. Once more: man to the rescue!
# netstat -af inet -P tcp
The output (see image below) looks good. Let's do one last check and simply connect to the default SSH port on the VM: Success. SSHd is definitely running and accepting connections.
Testing if the SSH daemon is running (PNG)
Alright, so much for very basic service management! It's just a test box, but I don't really like sshing into it as root. Time to add a user to the system. How hard could that be?
Ok, there's no user database like on FreeBSD or anything like that. It's just plain old _/etc/passwd_ and _/etc/shadow_. How boring. So let's just create a user and go on with the next topic, right?
# useradd -m kraileth
UX: useradd: ERROR: Unable to create home directory: Operation not applicable.
Uh oh... What is this? Maybe it's not going to be so simple after all. And really: Reading through the manpage for useradd, I get a feeling that this topic is everything - but certainly not boring!
There's a third file, _/etc/user_attr_, involved in user management. Users and roles can be assigned extended attributes there. Users can have _authorizations_, _roles_, _profiles_ and be part of a _project_. I won't go into any detail here (it makes sense to actually read the fine manpages yourself if you're interested). Now if you're thinking that some of this might be related to what FreeBSD does with _login.conf_, you're on the right track. I cannot claim that I understood everything after reading about it just once. But it is sufficient to get an idea of what sort of complex and fine-grained user management illumos can do!
Content of /etc/user_attr (PNG)
Ok, while this has been an interesting read and is certainly good to know, it didn't solve the problem that I had. The _useradd_ manpage even has a section called DIAGNOSTICS where several possible errors are explained - however the one that I'm experiencing here isn't. And that's a pitty, since some of the ones listed here are pretty self-explanatory while "Operation not applicable" isn't (at least for me).
I read a bit more but didn't find any clue to what's going on here. When my man skills failed me, I turned to documentation on the net. And what better place to start with than the OmniOSce Wiki?
OmniOSce Wiki: General Administration
When it comes to local users, the first sentence (ignoring the missing word) reads: *On OmniOS, home is under automounter control, so the directory is not writable.*
Ah-ha! That sounds quite a bit like the reason for the mysterious "not applicable"! That should be hint enough so I can go on with manpages, right?
# apropos automounter
/usr/share/man/whatis: No such file or directory
# man -k automounter
/usr/share/man/whatis: No such file or directory
Hm... Looks like the whatis database does not exist! Let's create it and try again:
# man -w
# apropos automounter
# apropos automount
autofs(4) - automount configuration properties
automount(1m) - install automatic mount points
automountd(1m) - autofs mount/unmount daemon
There we go, more pages to read and understand.
The automounter is another slightly complex topic (and the fact that the wiki mentions _/export/home_ while useradd seems to default to _/home_ doesn't help to prevent confusion, either). So I'm going to sum up what I found out so far:
It seems that people at Sun had the idea that it would be nice to be able work not only on your own workstation but at any other one, too. Managing users locally on each machine would be a nightmare (with people coming and going). Therefore they created the _Yellow Pages_, later renamed to _NIS_ (Network Information Service). If you have never heard of it, think LDAP (as that has more or less completely replaced NIS today). Thus it was possible to get user information over the net instead of from local passwd and friends.
The logical next step was shared home directories so employees could have fully networked user logins on multiple machines. Sun already had _NFS_ (Network File System) which could be used for the job. But it made sense to accompany it with the _automounter_. So this is the very short story of why home directories are typically located in _/export/home_ on Solaris-derived operating systems: They were meant to be shared via NFS!
So we have to add a line to _/etc/auto_home_ to let the automounter know to handle our new home directory:
* localhost:/export/home/&
Configuring the automounter for the home directory (PNG)
Most of the two automounter configuration files are made up of the CDDL (pronounced "cuddle") license - I've left it out here by using tail (see picture). After adding the needed rule (following the _/export/home_ standard even though I don't plan on using shared home directories), the _autofs_ daemon needs to be restarted, then the user can finally be created:
# mkdir /export/home
# useradd -m -b /export/home kraileth
# passwd kraileth
So with the user present on the system, we should be able to SSH into the local machine with that user:
# ssh kraileth@localhost
SSHing into the system locally (PNG)
Success! Now all that remains is bringing the net up.
The next post will be mostly network related and feature a conclusion of my first impressions. I hope to finish it next week.
