Mjanja Tech

Chini ya maji, just for the lulz

Useradd bash script for 389 LDAP

By Alan on June 10, 2013

We started using 389 LDAP (aka Fedora Directory Server) for user and group management in our research computing environment. Instead of managing users, groups and passwords on each and every machine, we just put them in LDAP and have all the machines authenticate users centrally; it’s not rocket science (people have been doing centralized LDAP authentication for decades), but it’s certainly non trivial.

As 389 is a Red Hat technology, it integrates very well with other Red Hat technologies like RHEL (errm, CentOS!). Installation and configuration is well documented, but the out-of-the-box administration tools (389-console) are complete rubbish; the fonts are nearly unreadable, the windows don’t show up in GNOME 3.x window overview (good luck if you accidentally move something over one), the GUI makes it easy to mess up your directory (right click -> delete without selecting a user first? Big mistake!), and also it’s just not very fast/convenient compared to traditional CLI-based *nix utilities like useradd.

So I decided to write my own wrapper script for adding users from the command line, 389_useradd.sh. It was originally based on the example script in the Red Hat Netgroup whitepaper, but has been significantly updated.

Usage

Using it is simple; the only mandatory options are first and last name:

./389_useradd.sh -f Alan -l Orth > /tmp/aorth.ldif

Otherwise, if you mess up somehow, it will print out usage instructions (aka -h).

./389_useradd.sh 
Usage: ./389_useradd.sh -f FirstName -l LastName -u username [ -i userid -g groupid -p password]

Basically, it outputs an LDIF for a new user and corresponding primary group for that user. You can save the LDIF to disk or pipe it directly to ldapmodify. If user/group id are unspecified it will generate unique values based on the latest in the directory (basically, latest + 1). You can still specify these on the command line if you want to, but it seems more useful to be able to add users without checking your LDAP for the last uid first. This is what the *nix useradd does, so it makes sense to be able to use the same thing here.

Example output

/tmp/aorth.ldif, from above:

dn: uid=aorth, ou=People, dc=example,dc=org
changetype: add 
givenName: Alan Orth
sn: Orth
loginShell: /bin/bash
gidNumber: 901 
uidNumber: 901 
objectClass: top 
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
uid: aorth
gecos: Alan Orth
cn: Alan Orth
userPassword: redhat
homeDirectory: /home/aorth

dn: cn=aorth, ou=Groups, dc=example,dc=org
changetype: add 
gidNumber: 901 
memberUid: aorth
objectClass: top 
objectClass: groupofuniquenames
objectClass: posixgroup
cn: aorth

Import the LDIF using ldapmodify. For example:

ldapmodify -h ldap.example.org -D "cn=Directory Manager" -W -f /tmp/aorth.ldif

Todo

While the simple use case of adding a user works, there are still some things I’d like to be able to do from the command line:

  • Ability to add groups, à la groupadd
  • Ability to add/remove users from arbitrary groups, à la gpasswd
Fork me on GitHub

Posted in Linux | Tagged 389, bash, CentOS, LDAP, LDIF, Linux | 2 Responses

Update ownCloud stable from tarball

By Alan on June 7, 2013

When I first installed ownCloud I did a git-based install, as I like to be able to git remote update and then git merge origin/stable. This works really well for DokuWiki, WordPress, Gallery, and other web applications, but was really a pain in the ass with ownCloud; it seems the git-based workflow is really meant for developers (not advanced users!).

I was pleased to find that updating ownCloud stable from a tarball is very straightforward. Note, I’ve only tried updating between small point releases (ie, 5.0.6 -> 5.0.7), so the jury is still out on “major” upgrades (ie, 5.x -> 6.x).

Upgrade instructions

As root, move to the location of your ownCloud installation:

$ sudo su -
# cd /var/www/html

Download the latest tarball and extract it right over your old installation:

# wget http://download.owncloud.org/community/owncloud-5.0.7.tar.bz2
# tar xf owncloud-5.0.7.tar.bz2

Then navigate to https://yourowncloud.com and you’ll see a message about updating your database to the latest version.

Posted in Linux | Tagged ownCloud | Leave a response

Reset LDAP server in Redmine sqlite database

By Alan on June 5, 2013

Our Redmine instance authenticates users against our institute’s LDAP server. The other day they moved the LDAP service to a new machine and the IP changed, which locked us out of Redmine. If this happens to you, you can easily change the LDAP server in the Redmine database. We’re using sqlite, but the concept should be the same for other database backends Redmine supports.

This sqlite statement says it all:

sqlite> update auth_sources set host="172.26.0.11" where id=1;

Longer version

Here’s a little more background…

Assuming your Redmine instance is in /opt/redmine, your sqlite database should be /opt/redmine/db/redmine.db. Become root, and then move into your Redmine directory:

$ sudo su -
# cd /opt/redmine

Open the database and then turn headers on so we can investigate the database in a little more detail:

# sqlite3 db/redmine.db
sqlite> .headers on

From looking at the list of tables (.tables), it’s pretty obvious that the authentication is configured in auth_sources.

sqlite> select * from auth_sources;
id|type|name|host|port|account|account_password|base_dn|attr_login|attr_firstname|attr_lastname|attr_mail|onthefly_register|tls
1|AuthSourceLdap|Example Active Directory|172.26.0.218|389|example\aorth|imsosexy|dc=example,dc=org|sAMAccountName|givenName|sn|mail|t|f

The LDAP server’s IP is listed under the host column, so we just need to update it:

sqlite> update auth_sources set host="172.26.0.11" where id=1;

Now we can see that the IP has changed:

sqlite> select * from auth_sources;
id|type|name|host|port|account|account_password|base_dn|attr_login|attr_firstname|attr_lastname|attr_mail|onthefly_register|tls
1|AuthSourceLdap|Example Active Directory|172.26.0.11|389|example\aorth|imsosexy|dc=example,dc=org|sAMAccountName|givenName|sn|mail|t|f

… and hopefully Redmine will let you log in now!

Posted in Linux | Tagged LDAP, Redmine, sqlite3 | Leave a response

libvirt “unable to create vcpu group” on linux-ck kernel

By Alan on May 26, 2013

I’ve been using Con Kolivas’ linux-ck patch set for a few years now. If you’ve ever asked yourself “It’s 2013, why does my music playback skip when I do too many things on my computer?!” then you probably need to look if your distro has a ck-patched kernel. A large part of the ck patch set is the “Brain Fuck Scheduler” (BFS), a greatly-simplified scheduler of CPU time slices which aims to improve interactivity of the desktop during all sorts of workloads.

Lately I’ve been getting weird errors when trying to start virtual machines managed by libvirt:

# virsh start cm7-ubuntu-12.04.1
error: Failed to start domain cm7-ubuntu-12.04.1
error: Unable to create vcpu cgroup for cm7-ubuntu-12.04.1(vcpu: 0): No such file or directory

As far as I could tell the errors were random; sometimes rebooting helped, etc. I couldn’t understand why until recently when I was reading the comments of some (linux-ck maybe?) Arch Linux User Repository package and then it clicked…

BFS doesn’t support cgroups

It turns out that BFS doesn’t support cgroups, and libvirt relies heavily on cgroups. So you need to run a kernel which supports cgroups if you want to use libvirt. Otherwise just stick to straight KVM or VirtualBox for all your virtualization needs.

It’s not a huge deal for me, I’m really just glad the mystery is solved. Hopefully I’m pleasantly surprised with how mainstream Linux’s default Completely Fair Scheduler (CFS) has come along. ;)

BFS is still cool

In implementing BFS Con removed thousands of lines of code from the Linux kernel’s scheduler implementation, greatly simplifying the scheduling process. The idea behind it is dead simple. As Con explained once, BFS is basically like having one master queue to service several supermarket checkers (as opposed to each checker having his/her own queue). There’s a video explaining this type of queuing theory on YouTube here: Why the other line is likely to move faster.

Posted in Linux | Tagged BFS, cgroups, libvirt, Linux | Leave a response

Remove “PRIV” ID3 tag from Google Play Music MP3s

By Alan on May 26, 2013

I bought an album on Google Play Music today. Upon inspecting the ID3 tags I noticed a few ugly PRIV tags, but I couldn’t figure out how to get rid of them; none of the ID3 tag editors (puddletag, eyeD3, easytag, etc) or MP3 players (Quod Libet, Ex Falso, Rhythmbox, etc) would even display them.

$ eyeD3 02\ The\ Game\ of\ Love.mp3 
02 The Game of Love.mp3 [ 12.33 MB ]
-------------------------------------------------------------------------------
Time: 05:22     MPEG1, Layer III        [ 320 kb/s @ 44100 Hz - Stereo ]
-------------------------------------------------------------------------------
ID3 v2.3:
title: The Game of Love
artist: Daft Punk
album: Random Access Memories
recording date: 2013
track: 2/13             genre: Electronic (id 52)
FRONT_COVER Image: [Size: 43274 bytes] [Type: image/jpeg]
Description: 

PRIV: [Data: 42 bytes]
Owner Id: Google/StoreId
PRIV: [Data: 25 bytes]
Owner Id: Google/StoreLabelCode
PRIV: [Data: 1073 bytes]
Owner Id: Google/UITS

It turns out the PRIV tag is actually part of the ID3v2 (2.3) specification (and I guess they’re technically frames, not tags), and it’s really easy to get rid of using eyeD3:

$ eyeD3 --remove-frame PRIV *.mp3

All clean now!

Posted in Linux | Tagged Google Play Music, mp3 | 1 Response

Next »

Some rights reserved.

Powered by WordPress, Hybrid, and Hybrid Kangaroo Code.