January 2011

Speaking of ugly code

The following violates many coding principals that I normally hold true to, but it was actually cool to code using the string variables as a stack.


#!/usr/bin/perl

# print hostlets
#
# 192.168.$i.0
$titan = "";
for ($i = 0; $i < 11; $i++) {
        $j = 0;
        $l = 0;
        $m = 0;
        $n = 0;
        $monster = "";
        $groupzilla = "";
        while ($j < 256) {
                $monster .= " hostlet_" . $i . "_" . $l;

                print "hostlet_" . $i . "_" . $l . " ";
                for ($k = 0; $k < 10 && $j < 256; $k++) {
                        print "(192.168.$i.$j,,) ";
                        $j++;
                }
                print "\n";
                $l++;

                if (($l % 5 == 0) || $j >= 255) {
                        $groupzilla .= " monster_" . $i . "_" . $m;
                        print "monster_" . $i . "_" . $m . $monster . "\n";
                        $monster = "";
                        $m++;
                }
        }

        $titan .= " groupzilla_" . $i;
        print "groupzilla_" . $i . $groupzilla . "\n";
}

print "titan" . $titan . "\n";

Allowing root ssh logins to Solaris machines

I’ve been away from Solaris for 5 months, but I need some VMs for NFSv4 testing, which means beating my head against modernization such as RBAC, pfexec, and NWAM.

I prefer to treat my lab Unix machines as inter-changable boxes and do all of my configuration up front. I want to be able to do an SSH root login, especially if the system goes out of the way to make that hard.

There are currently 3 things you have to do to violate this security truism on either OpenSolaris or Solaris 11:

1) Modify PermitRootLogin to yes in /etc/ssh/sshd_config.

2) Comment out the “CONSOLE=/dev/console” line in /etc/default/login.

3) Remove “;type=role” from the root entry in /etc/user_attr.

Really nasty Solaris 11 install

I just installed two VMs with the Solaris 11 express (snv_151a) and when I turned off nwam, one worked and the second did not:

svcadm disable svc:/network/physical:nwam
svcadm enable svc:/network/physical:default

The network would come up, both ifconfig and netstat -rn showed reasonable values, but the machine would only ping iff nwam were turned on.

It turned out to be ipfiltering:


root@snarf:~# ping 172.16.1.2
ping: sendto Network is unreachable
root@snarf:~# ipfstat -io
block out log all
pass out quick on lo0 all
pass out quick proto udp from any to any port = bootps
block in log all
pass in quick on lo0 all
pass in quick proto udp from any to any port = bootpc
root@snarf:~# svcadm disable svc:/network/ipfilter
root@snarf:~# ping 172.16.1.2
172.16.1.2 is alive
root@snarf:~# ipfstat -io
empty list for ipfilter(out)
empty list for ipfilter(in)

It was not enabled on the first machine, but was on the second. I have no clue what I did differently in the first install.

Configuring Fedora Core 14 network interfaces in a dual-hosted VM

I’ve got several VMs running with eth0 being bridged and eth1 being host only. I see the routes:

[thomas@mage ~]$ ip route
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.21 
172.16.1.0/24 dev eth1  proto kernel  scope link  src 172.16.1.3 
default via 172.16.1.1 dev eth1

The problem being that is flipped from what I want for the default route. I suspect the issue is that eth0 is set up to be configured via DHCP.

I read a bit and it was suggested that not only does /etc/sysconfig/network-scripts/ifcfg-eth0 have to have:

DEFROUTE=yes

But /etc/sysconfig/network-scripts/ifcfg-eth1 should have:

DEFROUTE=no

I made that change and cleared that hurdle:

[thomas@mage ~]$ ip route
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.21 
172.16.1.0/24 dev eth1  proto kernel  scope link  src 172.16.1.3 
default via 192.168.1.1 dev eth0 

FWIW, here are my config files:

[thomas@mage ~]$ more /etc/sysconfig/network-scripts/ifcfg-eth?
::::::::::::::
/etc/sysconfig/network-scripts/ifcfg-eth0
::::::::::::::
DEVICE="eth0"
NM_CONTROLLED="no"
ONBOOT=yes
HWADDR=00:50:56:2E:52:F0
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
PEERROUTES=yes
IPV6INIT=no
UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
::::::::::::::
/etc/sysconfig/network-scripts/ifcfg-eth1
::::::::::::::
DEVICE=eth1
HWADDR=00:0C:29:97:74:DB
TYPE=Ethernet
BOOTPROTO=none
IPADDR=172.16.1.3
PREFIX=24
GATEWAY=172.16.1.1
DNS1=172.16.1.2
DOMAIN=internal.loghyr.com
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
UUID=539d9802-fe1a-4b44-8d80-8a03f35aa844
ONBOOT=yes
DEFROUTE=no

How to edit DHCP server for Fusion

Crap, I am mixing versions of Fusion down below and it is partly because I do not have a clean install of Fusion on my laptop! I do on the iMac and that is what is telling me I have different systems!

Re: Scripts to manage Fusion network settings is a good place to see the differences.

See Controlling DHCP for VMWare Fusion VMs!

Note: I had to edit

/Library/Application Support/VMware Fusion/networking

and also reboot the MacBook to get this to work.

VMware Fusion Virtual Network Configuration, 27 August 2010 has a different approach.

To actually change the domain-name, you will want to edit vmnet-dhcpd.conf:

KinMage:VMware Fusion thomas$ grep domain-name vmnet-dhcpd.conf
# We set domain-name-servers to make some DHCP clients happy
    option domain-name-servers %hostaddr%;
    option domain-name "loghyr.com";
KinMage:VMware Fusion thomas$ sudo ./vmnet-cli -c
...
KinMage:VMware Fusion thomas$ sudo ./vmnet-cli --start
...