zero-knowledge

find cycle detected

2011-11-22T19:31:29+01:00

If you encounter the following error with make install

find: cycle detected for /lib/secure/32/
        find: cycle detected for /lib/crypto/32/
        find: cycle detected for /lib/32/
        find: cycle detected for /usr/lib/elfedit/32/
        find: cycle detected for /usr/lib/secure/32/
        find: cycle detected for /usr/lib/link_audit/32/
        find: cycle detected for /usr/lib/lwp/32/
        find: cycle detected for /usr/lib/locale/en_US.UTF-8/32/
        find: cycle detected for /usr/lib/locale/en_US.UTF-8/LO_LTYPE/32/
        find: cycle detected for /usr/lib/locale/en_US.UTF-8/LC_CTYPE/32/
        find: cycle detected for /usr/lib/32/

use ginstall in your Makefile instead of install. It seems just broken on solaris.

openindiana - curl CA failure

2011-11-14T19:09:54+01:00

There is a bug in openindiana that does not let you get the content of a page with curl, when it's secured with ssl. The cause of this is an option set on compile time. This option is the the path to the certificate storage. In the case of openindiana this is set to /etc/curl/curlCA, but all certificates reside in /etc/certs/CA/. This leads to the following error message, when you try it:

curl: (77) error setting certificate verify locations

To fix this, run the following script.

mkdir /etc/curl && cat /etc/certs/CA/*.pem > /etc/curl/curlCA

This writes all certificates of the default CA in the file curl is looking for and after that, it works.

openindiana - set up ssh with kerberos authentication

2011-11-12T21:45:01+01:00

This time, we will build a base kerberos setup. At the end, you will be able to login into another machine using kerberos only.

You need the following things, to make kerberos work:

a working dns server
2 servers

I will explain this setup on an openindiana system with 2 zones. kerberosp1 will be my kerberos machine and sshp1 will be my ssh server with kerberos support.

setup of kerberos

The setup of kerberos was pretty easy, after reading 3 tutorials about it. The essential part here is to decide, how the realm and the admin account should be called.

To start the setup, call kdcmgr. At first, it asks your realm, which you should name like your domain. After that, you have to generate an admin principal.A principal is like an account for a user or admin. But it's also used for services. I named mine kerberosp1/admin. Give it a safe password and you are done.

Now you should have an populated /etc/krb5/ directory. Open the file kdc.conf in that directory and search for max_life. It was set to 8 hours for me, which was too long. Adjust the value to 4h or 16h, like you want. I did the same with max_renewable_life.

Edit: You should add the following option in the realms section to your realm.

kpasswd_protocol = SET_CHANGE

Kerberos uses a separate protocol for changing the password of principals. A RPC like protocol is used in the solaris version and microsoft has another one too. So the only option compatible on all is SET_CHANGE. But to make things worse, the solaris default does not even work in an internal network. So just add this entry and save some stress from trying to find out, why this is not working.

setting up some accounts

To use the kerberos service, check first, if the kdc is running and start it, if it's not. For openindiana, the check is

svcs krb5kdc

which should return online.

After that, as root start the kerberos shell with kadmin.local. This is a management shell to create, delete and modify principals. Here we are going to create some policies. With these, we can set some minimal standards, like the minimum password length.

I created three policies. An admin, user and a service policy. These got the following settings:

admin
- minlength 8
- minclasses 3
user
- minlength 8
- minclasses 2
service
- minlength 12
- minclasses 4

This sets some password limitations for every principal group I have. minclasses is used for different types of characters. There are lower case, upper case, numbers, punctation and other characters. The create a new policy use the command addpol or add_policy with -minlength and -minclasses. You can simply type the command to get some help or read the man page.

After creating the policies, we have to create some principals. First, we should create one for ourselves. You can do this with the command addprinc or add_principal. Give it a policy with the argument -policy and a name. You will have to input a password for this principal according to the policies.

You can use this scheme to create user accounts too. For that, you can generate a password for them with the program pwgen. It's pretty helpful and can generate pretty complex passwords, so that should be best.

Now we need a principal for our ssh server. The name of this principal should be host/name_of_service.your.domain.name, so in my case, it is host/sshp1.prod.lan. But I did not want to generate any password and added the argument -randkey which generates a password according to the policies we set.

Now we have to export the key of the last principal into a keytab file, that can be read by the service, which wants to use it. This is done with the command ktadd like this

ktadd -k /etc/krb5.keytab host/sshp1.prod.lan

This generates our file in /etc/krb5.keytab. Copy this file into the kerberos directory (on openindiana it's /etc/krb5/) and delete the one on the kerberos host. This is important, as another execution of ktadd will append the next key to that file.

setting up ssh

For making ssh work with kerberos, we need /etc/krb5/krb5.conf and /etc/krb5/krb5.keytab. In the step before, we already moved the krb5.keytab. We can copy the krb5.conf from the kerberos server to the ssh server.

Now you can start the ssh deamon.

try to log in

For the test, we will try to connect to the ssh host from the kerberos host. So start a shell on the kerberos server and type kinit. This should ask for your password. If it was correct, klist should show you, that you have been granted a ticket.

Now try to open a ssh session to the server, with -v set for more informations and it should work.

problems that can occur

no default realm

The is the message

kinit(v5): Configuration file does not specify default realm when parsing name gibheer

which hints, that your /etc/krb5/krb5.conf is missing.

client/principal not found

The message

kinit(v5): Client 'foo@PROD.LAN' not found in Kerberos database while getting initial credentials

is a hint, that you forgot to add the principal or that your username could not be found. Just add the principal with kadmin and it should work.

ssh does not use kerberos

If ssh does not want to use kerberos at all, check for the GSSAPI options. These should be enabled by default, but can be disabled. If that's the case, add the following line to your sshd_config.

GSSAPIAuthentication yes

After a restart, ssh should use kerberos for authentication.

one last word

I have one last word for you: Kerberos does not do authorization!

That means, that kerberos can not say, if one principal is allowed to use a service or not. It just manages the authentication for you. If you want to manage the access, there are some possibilities for that. One is to use ldap, often used in conjunction with kerberos. Or you manage the passwd files or any other file yourself or you use a service like chef or puppet.

changelog

added some explanation to kpasswd_protocol

great resource to ipfilter

2011-11-05T03:43:41+01:00

In the need of a resource about ipnat/ipfilter I found http://obfuscation.org/ipf/ipf-howto.html. ipfilter is a packet filter running on Solaris and illumos distributions.

openindiana - how to get routing working

2011-10-29T16:01:11+02:00

This time, we are going to get routing working on the global zone for our other zones. You can replace the global zone with another zone too, as the setup is the same.

What's needed?

First, we need to install ipfilter, if it isn't already installed. To do that, just invoke

# pkg install ipfilter

This will install the package filter and NAT engine. Latter is the part, we want to use now.

We will asume, that the global zone has to interfaces with the following setup

bge0 -> 192.168.4.1/24
bge1 -> 192.168.5.1/24

configure ipnat

With ipnat installed, we need to write a small configuration. For this example, we set up routing for every machine in the subnet.

For that, open the file /etc/ipf/ipnat.conf and write the following lines:

map bge0 192.168.5.0/24 -> 0/32 portmap tcp/udp auto
                map bge0 192.168.5.0/24 -> 0/32

These two lines say, that all packages from the subnet to the rest shall be relabeled and forwarded.

After that, all we need to do is enable the ipfilter and the routing deamons with the following commands.

# svcadm enable ipfilter
                # routeadm -e ipv4-forwarding
                # routeadm -e ipv4-routing
                # routeadm -u

The last command checks if all deamons are running according to the settings. To see, which settings are set and what the deamons are doing, run the routeadm command without any arguments.

configure the zone

Now we fire up the zone to test, if we can get anywhere near routing. In our case, the zone only has one interface, so that it detects the router itself per icmp.

We can prove that very easy with

# netstat -rn

The default gateway should point to our global zone. To make a last test, you can ping an ip in another subnet. If the global zone says, this host is alive, the zone should do too.

A good IP to test is 8.8.8.8, as it is really easy to remember.

That was all. Have fun with your access

links and hints

You can get some more documentation to ipfilter and routing in the man pages of ipnat, ipf and routeadm. Some example rule sets for ipf can be found in /usr/share/ipfilter/examples/nat.eg.

openindiana - how to configure a zone

2011-10-29T15:14:16+02:00

In this short post, we will get a container running on a openindiana host. We will do some things in crossbow, but of the following stuff is just configuring the zone. At the end of this blog post, you will find some links to related pages.

some preparations

Make sure, that you have a free vnic created with dladm to use in the zone or else, we will have no network available. Further, we need a place on the filesystem, where our zone can be created. We need 500MB to 1.5GB of free space.

writing a zone configuration

In the first step, we have to write a zone configuration. You can use zonecfg directly, but it's better to write it into a textfile and let zonecfg read that file. That way, you can check the configuration into a vcs of your choice.

The config should look like this.

create -b
                  set zonepath=/zones/zone1
                  set ip-type=exclusive
                  set autoboot=false
                  add net
                  set physical=zone1
                  end
                  commit

With this configuration, we build a zone, which get's saved in /zones. /zones has to be a zfs partition or else the zone can not be created.

The sixth line sets the network device for the zone to the vnic zone1.

Now we feed the file to zonecfg and let it create zone1.

# zonecfg -z zone1 -f zone1.conf

installation of the zone

The next step is to install the zone with the command:

# zoneadm -z zone1 install

or clone it from a template with

# zoneadm -z zone1 clone template_name

Now we have to wait a bit and can write the next configuration file.

writing a sysidcfg

I wrote a rough post about the sysidcfg already, so take a look there, if you are interested in further details.

For this example, we use the following content.

name_service=NONE
                  nfs4_domain=dynamic
                  terminal=xterms
                  # the password is foobar
                  root_password=0WMBUdFzAu6qU
                  security_policy=NONE
                  network_interface=zone1 {
                    primary
                    hostname=zone1
                    default_route=NONE
                    ip_address=192.168.5.3
                    netmask=255.255.255.0
                    protocol_ipv6=no
                  }

booting the zone

When the installation process has ended, copy the file to /zones/zone1/root/etc/sysidcfg. This way, the zone can read the file on the first boot and set most of the stuff.

# zoneadm -z zone1 boot

To check if everything gets configured, log into the zone and check the output.

# zlogin -e ! -C zone1

It will take some time until the zone is ready to use, but it should not ask for further details. When the prompt shows, the configuration completed.

Now you can login into the zone and make further adjustments. Some topics will get their own blog entries here, so take a look at the other entries for help too.

links

Here are some links for further details to this topic:

How to use sysidcfg for zone deployment

2011-10-28T13:41:53+02:00

This is mostly for myself that I can remember how to use the least documented feature of Solaris and openindiana - the sysidcfg files.

These files help deploying new zones faster, as you don't have to configure them by hand afterwards. But what is the syntax and how can you use them?

Here is an example file

name_service=NONE
                    # name_service=DNS {domain_name= name_server=}
                    nfs4_domain=dynamic
                    timezone=Europe/Stockholm
                    terminal=xterms
                    root_password=
                    security_policy=NONE
                    network_interface= {primary hostname= default_route= ip_address= netmask= protocol_ipv6=yes}
                    network_interface= {hostname= ip_address= netmask= protocol_ipv6=yes default_route=NONE}`

The most important thing first: you don't need system_locale after openindiana 151 anymore. If you have it in your config, even with C, delete it or else the setup will not work!

If you don't have a dns record for your zone yet, set the @name_service@ to NONE. If you have already a record set, use the commented syntax.

The next interesting setting is root_password. Here you don't input the password in cleartext but crypted. I wrote a little script to generate this string. You can find the code here.

The network_interface part is pretty easy, if you take these lines as a dummy. If you have only one interface, you can name the first interface PRIMARY. That way, you have a bit less to write.

That's all so far. I will update this post, when I have figured out, what to fill into nfs4_domain and security_policy.

set environment variables in smf manifests

2011-09-26T14:35:10+02:00

If you are in the need to set an environment variable for an smf service, you are looking for envvar. It get's set in the service scope or in the exec_method scope. Here is a small example, how it's used.

This example sets the environment variable FOO to bar. This is espacially useful, when you have to modify PATH or LD_LIBRARY_PATH. Just don't forget, that you did it.

get pfexec back in Solaris

2011-09-16T19:08:39+02:00

If you tried Solaris 11 or OpenIndiana in a fresh installation, you may have noticed, that pfexec may not work the way you are used to. I asked in #openindiana on irc.freenode.org and I was told, that the behavior was changed. OpenSolaris was used to have an Primary Administrator profile which got assigned to the first account created on the installation. The problem with that is the same as on Windows - you are doing everything with the administrator or root account. To avoid that, sudo was introduced, which needs the password of your account with the default settings. What both tools are very different at what they do and at what they are good at. So it's up to the administrator to define secure roles where appropriate and use sudo rules for the parts, which have to be more secured.

If you want back the old behavior, these two steps should be enough. But keep in mind, that it is important that you secure your system, to avoid misuse.

there should be line like the following in /etc/security/prof_attr Primary Administrator:::Can perform all administrative tasks:auths=solaris.*,solaris.grant;help=RtPriAdmin.html
if there is, then you can add that profile to your user with usermod -P'Primary Administrator

It is possible to combine these two mechanics too. You could build a zone to ssh into the box with a key and from there, ssh with sudo and a password into the internal systems.

OpenIndiana 151a released

2011-09-14T08:15:00+02:00

After the release of PostgreSQL 9.1, today another great open source project released a new version - OpenIndiana.

OpenIndiana is based on a fork of OpenSolaris, named Illumos. It was announced in august 2010. OpenIndiana has evolved since that time and got a stable release 148 and today 151a. That release is very solid and got one thing, which Solaris 11 has and most likely will never have: KVM.

So from today you get a Solaris fork with crossbow, resource containers, zones and the kernel virtual machine, converted from linux to Illumos from the developers of Joyent. They built there own distribution, SmartOS, which is a bootable OS for managing a cloud like setup but without the zones.

So if you have a large Infrastructure and want to seperate some programs from each other or have some old infrastructure, try OpenIndiana and it's zones and kvm.