💾 Archived View for gemini.circumlunar.space › users › kraileth › neunix › eerie › 2018 › exploring_… captured on 2022-01-08 at 14:46:49. 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 October 2018. The article has been slightly improved.
This is the second part of my post about "exploring OmniOS in a VM". The first one showed my adventures with service and user management on a fresh installation. My initial goal was to make the system let me ssh into it: Now the SSH daemon is listening and I've created an unprivileged user. So the only thing still missing is bringing up the network to connect to the system from outside.
Exploring OmniOS in a VM (1/2)
Networking can be complicated, but I have rather modest requirements here (make use of DHCP) - so that should not be too much of a problem, right? The basics are pretty much the same on all Unices that I've come across so far (even if Linux is moving away from _ifconfig_ with their strange _ip_ utility). I was curious to see how the Solaris-derived systems call the NIC - but it probably couldn't be any worse than _enp2s0_ or something that is common with Linux these days...
# ifconfig
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
lo0: flags=200200849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
Huh? Only two entries for _lo0_ (IPv4 and v6)? Strange! First thought: Could it be that the type of NIC emulated by VirtualBox is not supported? I looked for that info on the net - and the opposite is true: The default VirtualBox NIC (Intel PRO/1000) is supported, the older models that VBox offers aren't!
Ifconfig output and fragment of the corresponding man page (PNG)
Obviously it's time again to dig into manpages. Fortunately there's a long _SEE ALSO_ section again with ifconfig(1M). And I've already learned something so far: *adm commands are a good candidate to be read first. _Cfgadm_ doesn't seem to be what I'm looking for, but _dladm_ looks promising - the short description reads: "Administer data links".
I must say that I like the way the parameters are named. No cryptic and hard to remember stuff here that makes you wonder what it actually means. Parameters like "show-phys" and "show-link" immediately give you an idea of what they do. And I'm pretty sure: With a little bit of practice it will work out well to guess parameters that you've not come across, yet. Nice!
# dladm show-link
LINK CLASS MTU STATE BRIDGE OVER
e1000g0 phys 1500 unknown -- --
Ok, there we have the interface name: _e1000g0_. I don't want to create bridges, bond together NICs or anything, so I'm done with this tool. But what to do with that information?
The ifconfig manpage mentions the command _ipadm_ - but it's kind of hidden in the long text. For whatever reason it's missing in SEE ALSO! I'd definitely suggest that it'd be added, too. More often than not people don't have the time to really read through a long manpage (or are not as curious about a new system as I am and thus don't feel like reading more than they have to). But anyways.
# ipadm create-if e1000g0
This should attach the driver and create the actual interface. And yes, now ifconfig can see it:
Interface e1000g0 created (PNG)
Almost there! Now the interface needs an IP address. Looks like _ipadm_ is the right tool for this job as well. I had some trouble to find out what an _interface-id_ is, though. The manpage obviously assumes the reader is familiar with that term, which was not the case with me. I tried to find out more about it, but was unable to locate any useful info in other manpages. So I resorted to the OmniOS wiki again and that helped (it seems that you can actually choose almost anything as an Interface ID but there are certain conventions). Ok, let's try it out and see if it works:
# ipadm create-addr -T dhcp e1000g0/v4
No error or anything, so now the system should have acquired an IPv4 address.
IPv4 address assigned via DHCP (PNG)
10.0.2.15, great! Let's see if we can reach the internet:
# ping elderlinux.org
ping: unknown host elderlinux.org
Ok, looks like we don't have name resolution, yet. Is the right nameserver configured?
# cat /etc/resolv.conf
cat: cannot open /etc/resolv.conf: No such file or directory
Oops. There's something not right here! If I configure my FreeBSD box to use DHCP that makes sure _resolv.conf_ is populated properly. The interface e1000g0 got an IP - so the DHCP request must have been successful. But did something break before the network was configured completely? Is the DHCP client daemon even running?
# ps aux | grep -i [d]hcp
root 551 0.0 0.1 2836 1640 ? S 18:52:22 0:00 /sbin/dhcpagent
Hm! I'm used to _dhclient_, but _dhcpagent_ is unknown to me. According to the manpage, it's the DHCP client daemon, so that must be what OmniOSce uses to initiate and renew DHCP requests. And obviously it's running. However the manpage solves the mystery:
Aside from the IP address, and for IPv4 alone, the netmask, broadcast address, and the default router, the agent does not directly configure the workstation, but instead acts as a database which may be interrogated by other programs, and in particular by dhcpinfo(1).
Ah-ha! So I have to configure things like DNS myself. Nevertheless the system should have received the correct nameserver IP. Let's see if we can actually get it via the _dhcpinfo_ command that I've just learned about. A look at the manpage as well as at the DHCP inittab later I know how to ask for that information:
# dhcpinfo -i e1000g0 DNSserv
192.168.2.1
Right, that's my nameserver.
Some lines from /etc/dhcp/inittab (PNG)
Is the routing information correct? Let's check.
# netstat -r -f inet
[...]
default 10.0.2.2 [...]
10.0.2.0 10.0.2.15 [...]
localhost localhost [...]
Looks good and things should work. One more test:
# route get 192.168.2.1
route to: fw.local
destination: default
mask: default
gateway: 10.0.2.2
interface: e1000g0
[...]
Alright, then it's probably not a network issue... But what could it be?
Eventually I found another hint at the wiki. Looks like by default OmniOSce has a very... well, _old-school_ setting when it comes to sources for name resolution: Only the _/etc/hosts_ file is used by default! I haven't messed with _nsswitch.conf_ for quite a while, but in this case it's the solution to this little mystery:
# fgrep "hosts:" /etc/nsswitch.conf
hosts: files
There are a couple of example configurations that can be used, though:
# ls -1 /etc/nsswitch.*
/etc/nsswitch.ad
/etc/nsswitch.conf
/etc/nsswitch.dns
/etc/nsswitch.files
/etc/nsswitch.ldap
/etc/nsswitch.nis
Copying _nsswitch.dns_ over _nsswitch.conf_ should fix that problem.
And really: Instead of getting a _ping: unknown host elderlinux.org_ now I get _no answer from elderlinux.org_ - which is OK, since my nameserver doesn't answer ping requests.
Now with the network set up correctly, it's finally time to connect to the VM remotely. To be able to do so, I configure VirtualBox to forward port 22 of the VM to port 10022 on the host machine. And then it's time to try to connect - and yes, it works!
SSHing into the OmniOS VM... finally! (PNG)
So much for my first adventure with OmniOSce. I had quite a few difficulties to overcome even in this very simple scenario of just SSHing into the VM. But what could have been a trivial task proved to be rather educational. And being a curious person, I actually enjoyed it.
I'll take a break from the illumos universe for now, but I definitely plan to visit OmniOSce again. Then I'll do an installation on real hardware and plan to take a look at package management and other areas. Hope you enjoyed reading these articles, too!
