Category: Technology/Internet

Kerberos and LDAP on OpenBSD 6.2

I recently started setting up Kerberos and LDAP for my home network.  While I don’t have a ton of users, it’s handy to be able to centralize account information and do single sign-on.  So far all I really have for clients are a server computer, laptop, and Raspberry Pi, but I find it quite handy even if it was kind of a pain to set up.

I have an older PC in the basement I use mostly when I need to work on the network or some other project and just need to quickly grab a web page or SSH into something.  I had been running Ubuntu Mate on this, since I like the Mate desktop and wanted to give this distro a try.  It ran, but not well.  The desktop was slow,  and it would take a minute to start something like Firefox.  This machine is 3 GHz Pentium 4 dual core with 1 GB of RAM.

I also use OpenBSD on and off, and like it a lot.  Since I was curious about how it does on the desktop I decided to give it a try, using the Lumina desktop environment.  It works well, and it feels noticeably faster than Ubuntu did on this hardware.  Initially I got it going just to get a quick desktop, but then I started thinking about getting it into my Kerberos realm.

This turned out to be a little tricky.  For one thing, OpenBSD uses Heimdal Kerberos, as opposed to MIT Kerberos, which the rest of my setup uses.  For another, doesn’t use PAM, like all (most?) GNU/Linux distros do, as well as FreeBSD.  RedHat’s SSSD is also not present, which has been a godsend on the other platforms.  OpenBSD can authenticate to sources such as Kerberos and LDAP, however, though there isn’t a whole lot floating around online about it (though of course the man pages help out a lot).  There’s also no support for authorization (eg, group information, UID number) for anything besides local files and NIS, which presents a further challenge.

A Quick Little Guide

I thought I’d post this here in cases it helps someone down the line, or in case I have to do this again myself.  🙂  I’ve pieced this together from information found online, as well as man pages.  Note that this doesn’t cover setting up the Kerberos/LDAP server(s), which is another topic on which there are other guides.  I used a combination of this guide for Debian, and this one for Ubuntu (even though my KDC runs Debian).  At the moment the exact details of the setup aren’t terribly important, but you should have some kind of Kerberos/LDAP implementation that authenticates users.

I just want to point out here, that although Active Directory is in fact one Kerberos/LDAP implementation, I don’t really have much experience with it, and this guide will not directly concern it or any peculiarities it may have.  In theory a lot of what you see here should be applicable, and hopefully it will be helpful.  In my travels I found this, which may be helpful if that’s what you’re trying to do.

Aside from the server, you should obviously have an OpenBSD system you want to have as your authentication/authorization client.  Have some test users kicking around helps too, both some local users on your OpenBSD system as well as a couple configured in Kerberos/LDAP to test authentication there.

I’m using OpenBSD 6.2, i386, but I think this should work on other platforms as well(?), particularly amd64.  Now a word of caution: this guide requires modifying some system files.  I myself screwed up at one point, causing my system to boot but not allow anyone to log in.  I recommend not only making backups of relevant files, but also reading a bit about single user mode.  Take a look at the root password reset guide in the OpenBSD handbook; you can also use single user mode to fix system files.  For running an editor, you may also want to take a look at this if you get any errors in single user mode.

Kerberos

First, we’ll install Kerberos, which will handle authentication.  That is, this will check a user’s password and verify they are who they say they are.  I assume that you have a realm, EXAMPLE.COM, with a KDC/admin server kerberos.example.com.

Note that in this guide, in a code snippet meant to be run at the command line, # indicates the root prompt.  However, in a file, # will indicate a comment.

To start, we’ll need to install some packages.  From the command prompt:

# pkg_add heimdal heimdal-libs login_krb5

Next, you’ll want to modify your path so that you actually have access to the different Kerberos tools.  In .profile, look for that PATH line and add /usr/local/heimdal/bin like this:

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin:/usr/local/heimdal/bin

You may want to make the same modification in /etc/skel/.profile, so that it’s propagated to new users.  Next, modify /etc/rc.conf.local and add teh shlib_dirs line.  I had made other modifications in setting up my desktop, so for me that file now looks like this:

portmap=YES
portmap_flags=
shlib_dirs=/usr/local/heimdal/lib
xenodm_flags=

The reason for that is that Heimdal is installed under /usr/local/heimdal, which is also where its shared libraries are.  This tells the rest of the system where they are.  (You may have to reboot after saving this change.)

Next, we’ll start putting in some Kerberos details.  In the file /etc/kerberos/krb5.conf, modify it to reflect your situation (ie, your own realm and kdc/admin server):


# $OpenBSD: krb5.conf,v 1.1 2014/07/13 14:10:13 ajacoutot Exp $
#
# See krb5.conf(5) and the heimdal info(1) page for more information.

[libdefaults]
# local realm(s)
default_realm = EXAMPLE.COM

[realms]
EXAMPLE.COM = {
# list of KDC(s) for this realm
kdc = kerberos.example.com

# admin server for this realm
admin_server = kerberos.example.com

default_domain = EXAMPLE.COM

}

[domain_realm]
.EXAMPLE.COM = EXAMPLE.COM

[kadmin]
# default salt string
default_keys = v5

[logging]
# log to syslog(3)
kdc = SYSLOG:INFO:DAEMON
kpasswdd = SYSLOG:INFO:AUTH
default = SYSLOG:INFO:DAEMON

By this point you should be able to use tools like kinit, klist, etc. on the OpenBSD client.  What we want to do now is set up a host principal for this machine, and a keytab for it.  At this point, I would like to mention that I had a problem with this on OpenBSD: normally I create the principal by logging into my KDC, then creating the principal in kadmin, then logging into the client and running kadmin as root.  Because of the krb5.conf configuration, you basically use kadmin to copy the principal from the KDC to the local keytab.  Unfortunately, when I tried to do this from my OpenBSD machine it hung.  I’m not sure what was going on, or if it was some kind of Heimdal vs MIT Kerberos issue, but I ended up having to copy the keytab over manually.

Log in to your KDC, and run the following.  Note that in the addprinc command I have the -x dn=”uid..” line – this is because my KDC uses LDAP as its backend (not just for authorization), and I keep the principal with other information about that computer.  (See the Ubuntu guide I linked earlier for more information.)  You can leave that out if you don’t do this.

The session should look something like this (again, my KDC is running MIT Kerberos):

root@kerberos:~/kdc# kadmin -p kerberosadminuser
Authenticating as principal kerberosadminuser with password.
Password for kerberosadminuser@EXAMPLE.COM: 
kadmin: addprinc -randkey -x dn="uid=openbsdclienthostname$,ou=computers,dc=example,dc=com" host/openbsdclienthostname.example.com
WARNING: no policy specified for host/openbsdclienthostname.example.com@EXAMPLE.COM; defaulting to no policy
Principal "host/openbsdclienthostname.example.com@EXAMPLE.COM" created.
ktadd -k /path/to/some/file.keytab host/openbsdclienthostname.example.com@EXAMPLE.COM
quit

The above copies the host principal to /path/to/some/file.keytab, which you need to then transfer to the client – rename it to /etc/heimdal/krb5.keytab.  Transfer it using a secure method, like SSH or a thumb drive.  Assuming you put it in /root:

# mv /root/file.keytab /etc/heimdal/krb5.keytab
# chown root:wheel /etc/heimdal/krb5.keytab
# chmod 600 /etc/heimdal/krb5.keytab

At this point, you should be able to get a Kerberos principal yourself:

# klist
klist: No ticket file: /tmp/krb5cc_0
# kinit krbuser
krbuser@EXAMPLE.COM's Password: 
# klist
Credentials cache: FILE:/tmp/krb5cc_0
 Principal: krbuser@EXAMPLE.COM

Issued Expires Principal
Mar 4 15:48:38 2018 Mar 5 15:48:38 2018 krbtgt/EXAMPLE.COM@EXAMPLE.COM

Next, we want to be able get that principal when we log in.  Earlier, we installed login_krb5, which will do this (along with of course letting us log into the system without a passwd entry).

Edit /etc/login.conf, and look for the default:\ section as shown below:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin:\
:umask=022:\
:datasize-max=512M:\
:datasize-cur=512M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:auth=-krb5-or-pwd:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

The line to add is “:auth=-krb5-or-pwd:\” just above “:tc=auth-defaults:\”.  This line allows you to use Kerberos as a login mechanism, but falls back to checking local files if that fails.

This should be about it – you can test authentication to a Kerberos account, but note that we don’t have authorization.  In other words, the system still has to look to local files for things like user and group information.  To test now, create a local account with a home directory, group, etc. in OpenBSD (as root):

# useradd krbuser

Follow the prompts that come up.  The password doesn’t really matter, just use something different than what you set up for the Kerberos principal.  Then, log in to the console as that user using the Kerberos principal’s password.  After logging in, you should be able to run klist and see that user’s principal.  (If you get a “Command not found” or similar error, make sure that /usr/local/heimdal/bin is in your path, see above.)

LDAP

Assuming you got the Kerberos part working, now might be a good time to take a break, get a fresh coffee, etc.

As I mentioned before, LDAP is used for authorization, that is user info like groups, login shells, etc.  Unfortunately, OpenBSD doesn’t actually support using LDAP for authorization, only Network Information System (NIS, aka YellowPages or yp, which most of the tools are named for).  Luckily, there’s a translator we can use that comes with the base system, ypldap.  This basically makes the LDAP directory look like a YP (NIS) server.

I couldn’t find much online about using this with OpenBSD 6.2, but I think I got it working.  I found two pages on this, both of which are older.  Both of these start by talking about login_ldap, which I ended up installing, but which isn’t really needed.  That’s if you want to authenticate to LDAP (ie, if that’s where you’re storing your passwords).  In our case, that’s already taken care of by login_krb5.

To start, create /etc/ypldap.conf.  I recommend copying the example:

# cp /etc/examples/ypldap.conf /etc/ypldap.conf

There is another caveat – on my Linux clients, I use GSSAPI with the host principal to authenticate to the LDAP database.  On OpenBSD, ypldap does not support this (that I could tell).  This means you’ll need a user that can just bind to LDAP by itself, for instance using the userPassword attribute.  This user needs to be able to read through your directory to get user/group information.  Also, while I don’t have it set up here, you should probably be using SSL/TLS with your LDAP server.

Now, edit this file like the following (I’ve added some of my own comments) to reflect your own setup:

# $OpenBSD: ypldap.conf,v 1.1 2014/07/11 21:20:10 deraadt Exp $

domain "example.com" #This is just the name of your realm
interval 120 #How often to pull data from the LDAP database, in seconds
provide map "passwd.byname"
provide map "passwd.byuid"
provide map "group.byname"
provide map "group.bygid"
provide map "netid.byname"

directory "kerberos.example.com" { #This is the machine hosting your LDAP directory
# directory options
binddn "uid=openbsdclienthostname$,ou=computers,dc=example,dc=com" #User to bind to LDAP as
bindcred "mypassword" #Password for above user
basedn "dc=example,dc=com"
# starting point for groups directory search, default to basedn
groupdn "ou=groups,dc=example,dc=com" #Change to reflect your setup

# passwd maps configuration (RFC 2307 posixAccount object class)
passwd filter "(objectClass=posixAccount)"

attribute name maps to "uid"
fixed attribute passwd "*" #Can leave this as is, we check passwords with Kerberos
attribute uid maps to "uidNumber"
attribute gid maps to "gidNumber"
attribute gecos maps to "cn"
attribute home maps to "homeDirectory"
attribute shell maps to "loginShell"
fixed attribute change "0"
fixed attribute expire "0"
fixed attribute class ""

# group maps configuration (RFC 2307 posixGroup object class)
group filter "(objectClass=posixGroup)"

attribute groupname maps to "cn"
fixed attribute grouppasswd "*"
attribute groupgid maps to "gidNumber"
# memberUid returns multiple group members
list groupmembers maps to "memberUid"
}

Next, we configure the YP client.  I recommend taking a look at the relevant page in the FAQ, for reference.  Since we basically just set up an YP server, we want to tell the client where to find it:

# echo 'example.com' > /etc/defaultdomain
# echo '127.0.0.1' > /etc/yp/example.com

To have the system use the YP client, make the following changes to /etc/master.passwd and /etc/group:

# echo '+:*::::::::' >> /etc/master.passwd
# pwd_mkdb -p /etc/master.passwd
# echo '+:*::' >> /etc/group

The first line sets the YP domain, while the second tells the YP client to look to our own host for the server (ypldap).  Next, enable some services:

# rcctl enable portmap
# rcctl start portmap
# rcctl enable ypldap
# rcctl start ypldap
# rcctl enable ypbind
# rcctl start ypbind

In some of the other guides online, it was said that you had to edit /etc/rc.local to make sure that ypldap starts before ypbind.  For 6.2, I didn’t have to do this.

Now, you can reboot and check to make sure you have the above running:

# ps aux | grep yp
_ypldap 3982 0.0 0.1 540 1488 ?? Ip 4:55PM 0:00.01 ypldap: dns engine (ypldap)
_ypldap 85354 0.0 0.2 584 1608 ?? Ssp 4:55PM 0:00.01 ypldap: parent (ypldap)
_ypldap 56536 0.0 0.2 628 1600 ?? Ip 4:55PM 0:00.01 ypldap: ldap client (ypldap)
root 23124 0.0 0.1 384 960 ?? Ss 4:55PM 0:00.00 /usr/sbin/ypbind

You can also test lookup up user information using the id command:

# id krbuser
uid=5555(krbuser) gid=5555(krbuser) groups=5555(krbuser)

In the above, 5555 would be whatever uid/gid you set it up for.  (If you have the user from before, the one which was using the local OpenBSD files, you may want to use a different one to make sure you’re actually pulling from LDAP.)

Next test logging in with a Kerberos/LDAP user from the console.  Note that I did not look into creating users’s home directories automatically, so you’ll have to do that yourself.  (If I figure this out, I’ll post it, or if someone else knows, feel free to comment.)

Final Remarks

I like OpenBSD a lot, but this was kind of a pain.  Actually, it was a good learning experience, and it’s good to know that it’s possible.  I got to learn a little more about the internals, and once I started looking into it it wasn’t too bad, just different from what I’d been used to on Linux.  Let me know if you have any trouble with this, or if I missed anything (I’m putting this down partly from memory, after working on it on and off over a couple weeks.).

I did not manage to get Kerberized SSH working, that is being able to SSH to/from the OpenBSD client without entering a password.  I think this is because the builtin sshd doesn’t support it.  This might be something that could be changed by recompiling it, I’ll have to look into it in the future.

Posting from Hurd!

Nothing’s really occured to me to post in a while, so here’s something kind of random.  I’m actually posting this from GNU/HURD (specifically, the Debian distribution).  I played around with it, installed some software, and eventually got Xorg and Mate running, and then Midori:

Midori on a GNU/Hurd desktop.
Even Midori was kind of sluggish, but it was usable until it crashed.

So how is it?  Slow, for one thing.  Not terribly while just using the terminal, but the install process took hours.  The installer is the basic Debian installer, but things like copying files to the hard drive took longer than it seems like they would under GNU/Linux.  The same is true of just installing packages.  The desktop is of course noticeably sluggish as well, although using something like Openbox might improve things here.  This machine is an old Dell Optiplex, with a 1.6 GHz P4 and 2 GB of RAM (only 768 MB were picked up according to htop).  The graphics are Intel, which I think requires a kernel module on Linux, which of course isn’t supported here.  This probably explains the X slowness, but otherwise while this machine is old it’s felt faster on other OSes.

As far as applications, there are quite a few Debian packages ported over, and while not everything works very smoothly (I tried getting Apache and PHP going, only to have mod-php give an error about allocating shared memory) a lot of familiar programs are available and do run.  I dare say that there’s enough here to run an almost-functional desktop, although there is no sound or USB support (although keyboards/mice may work due to BIOS emulation).

So what’s the point of it then?  The concept of HURD, as in how it runs on top of a microkernel, is interesting.  Basically, this means that most of the services provided are run as a set of servers in userspace on top of a very minimal kernel (Mach in this case).  This is in contrast to Linux, in which these are all part of the kernel.  So, a fault in one of these servers doesn’t necessarily bring down the entire operating system.  In fact, these programs don’t even have to run as root.  This modularity may not be that much of a big deal on a normal desktop or server, considering how mature monolithic kernels like Linux are these days, but one could imagine an embedded or remote system where this could be desirable.  (Think some diagnostic that restarts one of the servers should it crash, so your entire space probe doesn’t have to reboot.)  Some other interesting features in GNU/HURD are the ability for a process to have more than one UID associated with it, as well as translators, which can expose things as part of the filesystem.  (For example, they can be used to mount an FTP share on a directory, similar to Fuse.)

I’m probably not going to be installing a GNU/HURD desktop on my main computer anytime soon.  In fact, I would guess that most people won’t be.  (There are probably exceptions, like people who work on GNU/HURD.)  For day-to-day use, it’s similar enough to a normal Debian (in this case, there are other HURD distributions) system that it’s not really worth the effort compared to the ease of the mainstream alternatives.  However, I’ll be keeping an eye on this project now and then.  Of course, there aren’t many people working on it compared to say Linux, so development isn’t exactly snappy.  But, depending on how it matures it could hold promise in some applications.  (Again I’m thinking of embedded systems.)

It’s also nice to have alternatives.  This is part of the reason I use GNU/Linux, and experiment with other OSes.  Even if HURD really isn’t ready now, it can actually be somewhat useable.  So, I consider it worth checking out, if only as an educational experience.  (And hopefully not as a cuationary tale.)

Easytether and Networkmanager

Easytether is a nice application you can use to tether your Android phone regardless of restrictions put in place by your carrier.  It consists of an app for the phone, as well as a program you run on your computer.  The two then talk to each other using the phone’s USB debugging abilities (ie, through ADB, which is integrated).  On the computer-side, Linux, Windows, and OS X are supported, and you can even use it with a Raspberry Pi.

I use this to occasionally tether my laptop, which runs Xubuntu.  On GNU/Linux, the PC-side application works by creating a tun (virtual) interface.  You start it from the command line like this ($ indicating the command prompt):

$ sudo easytether-usb

When I first did this (must have been a few years ago), Networkmanager would immediately detect the interface and manage it, so I didn’t really have to do anything else.  As soon as I started the program, I’d have a network connection.   This does not work with Xubuntu 16.04, however – the interface comes up, but I have to configure it manually.  No big deal, but now after running the above I have to do this:

$ sudo dhclient easytether-tap

Or this instead of dhclient, to do it manually:

$ sudo ifconfig easytether-tap 192.168.117.2
$ sudo route add default gw 192.168.117.1$ sudo sh -c ‘echo “nameserver 8.8.8.8” >> /etc/resolv.conf’

That works fine, but it’s kind of a pain.  Networkmanager is fairly capable these days, and it would be nice to make it do some of this for us again.  The reason it doesn’t is that, with the current version (1.2.0-0ubuntu0.16.04.2 on this machine), virtual interfaces that it didn’t create itself are ignored by default.  Luckily, there is a way we can make a new connection and automate things.  Unfortunately, this doesn’t seem to be possible with the panel applet in Xubuntu, but we can do it from the command line using nmcli.

In the above lines, easytether-tap is the default name of the virtual interface that the PC application creates.  First, let’s create a new connection named ‘phone’ that uses this interface.  Then, we’ll add a DNS server.  (Note that the below lines can be done as a normal user, no sudo needed.)

$ nmcli connection add ifname easytether-tap con-name phone type tun mode tap ip4 192.168.117.2 gw4 192.168.117.1
$ nmcli con mod phone +ipv4.dns 8.8.8.8

You could of course name it something other than phone.  Note that that configures the interface manually, which I just did for simplicity.  Also, 8.8.8.8 is Google’s public DNS, and you could substitute a different server IP.  Now, assuming you have easytether-usb started like in the first command in this post, you can bring the interface up like this:

$ nmcli connection up phone

And then bring it down like this:

$ nmcli connection down phone

And that’s it!  But, we still have to start easytether-usb when we plug the phone in.  It’s possible to automate that, too, using Networkmanager’s dispatcher scripts.  I created the following script, and saved it as 90easytether.sh:

#!/bin/bash

IFACE=$1
STATUS=$2

if [ “$IFACE” == “easytether-tap” ]
then
case “$STATUS” in
pre-up)
logger -s “Starting easytether-usb daemon”
easytether-usb
;;
down)
logger -s “Stopping easytether-usb daemon”
killall easytether-usb
;;
esac
fi

Now, move the script into the dispatcher.d directory, then change the ownership and permissions, and create a symlink to the script in the pre-up directory:

$ sudo mv 90easytether.sh /etc/NetworkManager/dispatcher.d/
$ cd /etc/NetworkManager/dispatcher.d
$ sudo chown root:root 90easytether.sh$ sudo chmod 755 90easytether.sh
$ cd pre-up.d/
$ sudo ln -s /etc/NetworkManager/dispatcher.d/90easytether.sh ./

Now, we need to start the dispatcher service, an enable it on boot:

$ sudo systemctl start NetworkManager-dispatcher.service
$ sudo systemctl enable NetworkManager-dispatcher.service

I also found I needed to restart Networkmanager itself:

$ sudo systemctl restart network-manager.service

Basically, that script is triggered by the pre-up and down actions, and starts and kills easytether-usb for us.  The symlink was necessary because Networkmanager needs anything that acts on this to be in the pre-up.d directory.  Now, you plug in your phone, then use the nmcli commands from above to bring the interface up and down, and that’s it!

One caveat: You need to be able to use USB debugging on your phone.  Also, you may have to confirm on your phone that you want to be able to connect from your PC or laptop first.  I also find that I have to mount my phone (IE, click on the icon on the desktop and browse to it in the file manager) before easytether-usb will connect.  Make sure you get Easytether working manually like at the beginning of this post, and you should be fine.  Have fun!

First Post (of 2013)!

Alright, New Year’s is over, and it’s 2013.  I didn’t put a whole lot of thought into resolutions, but here are a few things I’ve been thinking of regarding this site:

  • Projects.  I mentioned the inverter, and that and some other things have been kicking around in my head.  Now I want to start work on them and share.
  • Wiki.  This goes with the above, as I think it will be a better format for some things.  It won’t be for everyone to edit, but I think it will present certain bits of information in a better fashion than this blog.  It’ll also be a little easier to maintain.
  • Housekeeping.  I’ve been meaning to update the theme here, and also take a look at some backend stuff.
  • Feverdreams Update?  I’ve been thinking of trying to modernize the Fever Dreams mirror, if for no other reason than to play with some Web development stuff.  This would mainly be backend, as I wouldn’t want to disturb the pristine late-90s look.  🙂  I sometimes wonder about updating with new content, but that will remain to be seen as I really don’t have any.

Anyway, that’s about it.  Have a good remainder of Christmas or whatever.

No Icons on Cinnamon Desktop

I’ve posted before about Linux Mint, as well as using Xfce.  While I hadn’t gotten Cinnamon working on the older machine, I did realize that there is in fact an ebuild for this on Gentoo.  I’ve been trying it on a laptop, and have found it to be pretty nice.  However, after logging in a few times, I could no longer see any icons on my desktop, nor could I drag anything onto it.

This is caused by the filemanager, nemo, not starting at login and taking over the desktop.  Starting the file manager manually by clicking the taskbar icon brings the icons back, but this only lasts until you close it.  I wasn’t sure what was causing this, until I remembered that I still had Gnome3 installed, which uses nautilus to manage the desktop.  Cinnamon is derived from Gnome, and you can actually use gnome-session-properties to manage startup applications in both.  The problem was that both nautilus and nemo were trying to take over, and neither were winning.

I didn’t have gnome-session-poperties installed, but I got it by emerging gnome-media.  In the list of applications it listed ‘Files’ twice.  Find the one that starts nautilus (highlight it and click ‘Edit’, then see what command it uses) and disable it.  After logging out and logging in again I had my desktop back to normal.

Trying Linux Mint 13

Mint

I had been curious to try out Linux Mint (see also the Wikipedia entry) for a while now.  Basically, it’s a distribution based on Ubuntu, which aims to provide a better out-of-the-box experience by including some proprietary software.  Ie, when you install it, you shouldn’t have to install many codecs or whatever, as you do with Ubuntu.  It’s also gotten more and more attention as people have grown tired of UI changes with Gnome 3 and Ubuntu’s Unity, since its feel is closer to that of Gnome 2.  Partly because of this, Mint has grown in popularity, spreading and taking over like its namesake herb (though it still seems to be second to Ubuntu).  Because of this, I thought I’d give it a try.

I have an older desktop, actually the first one I built back in the early 2000s (I think around 2003 or 2004).  This machine is old, but not exactly decrepit – it’s a dual AMD MP2800 rig, with 1 GB of RAM and a 120 GB hard drive.  Not my most powerful computer, but it still works pretty well.  Since it wasn’t doing much I figured I’d use it to test Mint 13, the latest release as of this writing.  I’m not going to lie, I don’t really feel like doing a full review.  There are tons of those around, just go to Google.  However, I have some remarks and a random tip or two.

Overall, installation was a pain and took me several attempts.  Now, don’t get the wrong idea here, I don’t really blame Mint for this.  This machine does not have a DVD drive, and Mint 13 no longer distributes CD images – they’re too big.  Now, I tried using a USB stick, which seemed to work, but was also slow…  Because while the motherboard can boot from USB, the onboard USB is 1.1, and it won’t boot off the 2.0 PCI card I have in there.  Luckily, there is a guide on howto remaster the DVD image and shrink it.  Basically, you just remove some installed packages.  I didn’t have a Mint system already, so I had to mess around with the tool they mention in order to run it on an Ubuntu 12.04 system.  (Basically, you need to either install the mint-core package in Ubuntu, or download the .deb and force an install or extract it.  Sorry to gloss over this, but hopefully most people either have faster USB or a DVD drive. If someone wants instructions, I’ll try to put something together.)  I remastered the no-codec CD, and ended up removing samba, firefox, java, and a few other things.  This should get you an image small enough to fit on a CD.  When the install’s done, just use the package manager to put everything back (that you want).

So, I got the install rolling.  However, I then ran into a problem with the installer hanging toward the end of the process.  Everything seemed to finish, but the window would close and leave only the spinning mouse cursor to indicate something was happening.  After leaving it for a while, rebooting revealed a failed install.  A fix for that is here.  Basically, when the live CD (or USB stick or whatever) boots, open a terminal and type this:

sudo apt-get remove ubiquity-slideshow-mint

This should allow the install to finish.

Finally, the system would not detect my nVidia card.  This card is old, and requires the legacy drivers, which the proprietary driver manager was unable to find.  This was annoying, but I found a solution here.  That guide has you set up a repository for Ubuntu Oneiric, and install the Xserver from that distribution along with the legacy drivers.

After going through that, I had a working install!  Like I said, I don’t blame Mint.  Not too much, at least.  It would have been nice if there was some support still there for the older video card, but then again this hardware is ancient.  I can also understand why they don’t distribute CDs.  But there you go, I’m probably not the only one who will have to go through some hoops to get it running on something older.

There is one more problem, however.  Due to what I can only consider to be my older video card, the desktop effects are slow.  Too slow to be usable, in fact, so I turned them off.  This also means no Cinnamon desktop, although the fallback Gnome option is actually quite nice. I’ll probably use this system as it is for a while.  If you liked Gnome 2, and want an Linux distro that’s newer but has that kind of feel, I would highly recommend checking Mint out.  That said, I’m not sure I’d install this again, but that’s just me.  Overall, it’s very nice.

XFCE/Nautilus Hybrid Desktop

It’s been a while since posting here, but I haven’t forgotten about you :).  I’ve still been mulling over (read: procrastinating) on some things, but a lot of that has been put on hold due to some positive developments in my life which I will not go into.  However, I do have some other news:

  • Development on my inverter project continues, look for more information sometime in the future (who knows).
  • I recently received my Raspberry Pi, and am looking at making it into the server for this site.
  • I’ve also been considering ways to make the Pi run at least partially on solar power.  As I’ve mentioned before this would be a neat thing to have my server do, although there are some logistical obstacles.

That said, the rest of this post is not about anything mentioned in the above list.  Rather, it deals with my frustrations regarding Gnome.  I upgraded to Gnome 3 on my Gentoo machine, and for the most part was happy with it.  That is, once I got used to the layout.  I understand why people might not like it, but it didn’t bother me too much.  However, eventually it started getting unstable, as in certain things would make it crash.  At first it was not much of a problem, but then it started to get more and more random.  I switched to Fallback Mode, which I actually kind of liked too.  However, this too proved to crash a little too often.  (Note: I was also having some issues with the clutter-gst package and introspection USE flag not compiling, but I think my stability problems are related to the current nVidia drivers.)

The other day, a crash happened while playing around with the excellent EDA software KiCad, and that was it: time to migrate to something else.  I’d used Xfce in the past, and had been happy with it, although I usually stuck to Gnome because I was familiar with it most of all.  Desperate, I emerged it.  It’s a great environment as is, but it just felt lacking.  I wanted to manage my desktop like I did under Gnome, with my wallpapers and the like.  Actually, I wanted Gnome, but it just wasn’t working out.  This post will explain how I made this environment more like Gnome by using Xfce with Gnome’s Nautilus file manager.  It’s not difficult, and hopefully it will help someone out.

Xfce is a lightweight desktop, and I should point out that doing this sort of defeats the purpose of having it.  That said, I had the hardware resources to use Gnome more than comfortably, so this really isn’t an issue.  Also, if you really like it, you might consider a distribution that uses it by default, which will probably integrate it fairly well.

Anyway, assuming you’re switching from something else (Gnome in my case), to start with you’ll need to install Xfce.  To do this on Gentoo, I used the following command (as root):

emerge -avt xfce4-meta

(Note: The Gentoo Xfce Configuration Guide is a great place to check out if using this distro.)

Next, logout and log back in with Xfce selected as your desktop.  You should have a vanilla looking desktop, and now we want to have Nautilus manage the folders and icons.  Open the Settings Manager (Applications Menu->Settings), and click on Session and Startup.  Now, before I go on, I should say that we are going to determine what gets started when you log in to your Xfce desktop.  So, close everything you don’t want open (leave the Settings manager open though).  In the Session tab, you should see a list of running applications.  Select the xfdesktop program, and kill it.  Now click the Save Session button.

So now, Xfce isn’t managing the desktop.  Click the Application Autostart tab, and you will see a bunch of different services, some Xfce-related, some Gnome-related.  In my case there was one called Files, which I checked.  This basically runs the command nautilus -n, which has Nautilus manage the desktop.  (If you’re unsure, you can select it, hit Edit, and look at the command.)  I also activated some other things, like the SSH Key Agent.

Logging out and logging in again, you should now have Xfce panels, but with a desktop managed by Gnome that responds like it did before.  If you want, play with the Xfce panels, and you can make it look fairly Gnome-like.  It’s a little weird, but I’m happy with it.  It doesn’t have all the 3D effects of Gnome, but it’s responsive, and so far has been fairly stable.

Nautilus and vsftpd

Just recently I was playing around with setting up an anonymous FTP server using the excellent vsftpd software.  (The ‘vs’ is for ‘very secure’.)  To test this out, I decided to connect from Nautilus, on my Ubuntu laptop.  Unfortunately, I got an error like this:

Sorry, could not display all the contents of "/ on ftp.whatsmykarma.com"

So, I gave this a try instead with the commandline ftp client on this machine, and it worked fine.  This had me scratching my head, but I figured it out eventually.  Basically, the problem is one of passive vs active FTP – look a the Wikipedia page for more information.  As it turned out, the commandline FTP client was defaulting to active mode, which basically means that the server listens on one port, and connects to a port on the client (that is, the client has to have one open and listening) to make the transfer.  This is fine if you’re on a local network, or have a loose environment firewall-wise where the server can talk to the client this way.  However, because this setup is a bit more difficult, passive FTP was introduced – the server listens on one port and then some other random ports.  The client doesn’t have to listen, just connect to the server on port 21, and then get which other port it has to connect to on the server to actually do the transfer.  This is basically an improvement, but it still means we want to listen on more ports than just 21.  For whatever reason Nautilus only seems like passive FTP (which is probably a good thing), and was giving that error because I’d only forwarded port 21 on the server.

Now, the fix for this is simple, but before I give much of my vsftpd.conf file I would like to address a concern that will no doubt be brought up: FTP isn’t that great.  Well, not from a security standpoint, at least.  Normal FTP just sends everything in clear text, and with minimal effort someone who has access to the datastream (eg, the guy in charge of your company’s firewall, or someone on your wireless network) can easily get this information.  Perhaps your FTP login details are used elsewhere, like for logging into to a system account.  (Like, you sit at your workstation and login with those credentials, and someone else getting them means they can read your Email and delete your crap.)  These days there are better options, such as SFTP (basically an FTP-like protocol that tunnels over SSH, and only really needs OpenSSH) that are better for a lot of things.  However, FTP is nice for certain things, like if you have a server that hosts a bunch of big files you want to put up for download.  You can do this with anonymous FTP, with no need for sensitive usernames and passwords.  I’m going to assume that this is kind of why you’re looking into FTP, and that roughly you know what you’re doing.  (Note that it’s also possible to use FTP with SSL, which could be handy in some cases when you really want to use FTP with login info.)

Anyway, here’s what we have to do.  We want to use passive FTP, and configure vsftpd thusly.  To do this we need to forward port 21 to it (of course), but we also need to have it listen on another port to do the transfers.  Traditionally the FTP server would randomly pick a port from a range, but you really only need one.  I chose 2020.  It can be anything, so long as it’s above 1024.  This is because the server will try to bind it as a non-root user.

Now, the other thing the server will do when we tell it we want to go into passive mode is send an address for the client to connect to (with the given port).  In my case, I’m on a dynamic IP, so we would like to give it a hostname to use.  Luckily, vsftpd will allow us to do all this.  So, for a simple, anon-only FTP server that works in passive mode, here is my config:

listen=YES
local_enable=NO
anonymous_enable=YES
write_enable=NO
anon_root=/var/ftp
pasv_enable=YES
#
# Optional directives
#
#anon_max_rate=2048000
xferlog_enable=YES
listen_port=21
pasv_min_port=2020
pasv_max_port=2020
pasv_addr_resolve=YES
pasv_address=ftp.example.com

Change the details or add stuff to suit your setup.  Note that we have a pasv_min and pasv_max port, these can just be the same thing.  pasv_addr_resolv=YES just lets us specify a hostname.  And that’s that, restart vsftpd and enjoy FTP.

Projects

I’ve mentioned before that I’m into solar power, and that there are a couple projects I’m getting into.  Well, I’ve been thinking about a couple things for a long time, but I’m just now starting to get into serious development.  There are two things: a maximum powerpoint tracking (MPPT) charge controller, and a sine wave inverter/charger.  The first of these is a good tool for extracting extra power out of solar panels, while the second is instrumental in interfacing the DC and AC sides of a power system.  That is, the inverter/charger will allow you to get clean AC from your batteries, or charge them from a source already available.  Think computer UPS, but designed for a slightly different purpose.

There are various homebrew projects like these floating around the Internet, and I hope to contribute something.  By posting about these here, I hope that I remain focused on them :).  This should be interesting, and maybe even useful to someone.  I’ll try to give an update here and there as I come up with more of a solid design for both.

Gentoo Network Interfaces Problem

I recently had an issue on my Gentoo desktop which was sort of frustrating, but which I’ve since gotten past.  I turned my machine on one day, only to find the mouse and keyboard not responding once the login screen came up.  Now, most of the time that’s just what can happen after an update, if you don’t reemerge xorg-server and the xf86-input-whatever packages.  Problem was, I couldn’t log in, and for some reason, eth0 hadn’t come up.  This meant no SSH, either.

First, a little about my setup.  I have two network cards in this machine.  One is the onboard gigabit one, which is my main nic (eth0).  The other is an extra PCI one (eth1) that I have statically configured for cases when I want to do a direct transfer between machines, or troubleshoot (like in this case).  The problem was, eth0 wasn’t coming up, and was instead doing a DHCP timeout (as if it weren’t connected at all).  I checked the cables, all looked good.

I ended up booting into the System Rescue CD (which I recommend having on hand if you do anything with computers) and checking a few things out.  I checked /var/log/messages and found these lines:

Mar 27 15:18:56 fishingcat kernel: [   13.847407] ADDRCONF(NETDEV_UP): eth0: link is not ready
Mar 27 15:18:57 fishingcat dhcpcd[2401]: eth0: waiting for carrier

This had me puzzled, but then I found this:

Mar 27 15:27:12 fishingcat /etc/init.d/udev-mount[7333]: Udev uses a devtmpfs mounted on /dev to manage devices.
Mar 27 15:27:12 fishingcat /etc/init.d/udev-mount[7335]: This means that CONFIG_DEVTMPFS=y is required
Mar 27 15:27:12 fishingcat /etc/init.d/udev-mount[7336]: in the kernel configuration.
Mar 27 15:27:12 fishingcat /etc/init.d/udev-mount[7324]: ERROR: udev-mount failed to start
Mar 27 15:27:12 fishingcat /etc/init.d/udev[7323]: ERROR: cannot start udev as udev-mount would not start

Bingo.  I had remembered from an encounter at work that udev likes to create persistent naming rules for hardware.  This is a new feature, and is generally a good thing: it keeps eth0 as eth0 for the next reboot, same for eth1.  But with udev not starting, no dice.  So, following the error message, I enabled the appropriate kernel option in make menuconfig.  (For me, this was under Device Drivers -> Generic Driver Options -> Maintain a devtmpfs filesystem to mount at /dev.)

I’m not really sure what caused that to become disabled in the first place, but it’s fixed now, so there you go.