Category Archives: linux

Cyrus-Imap Administration

Every time I have to mess with cyrus-imap mailboxes I spend a half hour trying to figure out how to get cyradm to run. While I have by no means figured it all out, I do have one piece of lore worthy of being written down.

My imap server forbids plaintext logins unless they are within a TLS session, so /etc/imapd.conf has the setting allowplaintext: 0

But, cyradm uses imap authentication (witness all the failed attempts to get cyradm to authenticate putting entries in the /var/log/secure log using pam_unix imap:auth). The problem of course is that cyradm doesn’t have a tls session, so allowplaintext rejecting the plaintext password.

Reset /etc/imapd.conf to allowplaintext:1 temporarily, systemctl restart cyrus-imapd, and then, as root,  cyradm tarragon. Make all the mailboxes you want. Then reverse and turn plaintext back off.

Managing passwords on this server

This blog is running on my wmbuck.net server, tarragon, in the Amazon cloud. This server, in addition to hosting this blog, hosts about 20-25 websites (for friends, most of them very low traffic), including my own. It also operates mail for myself and a few others, and provides some other services.
One of the weaknesses has been that most of the people who use the server aren’t really very unix literate, and they don’t really WANT to be. Perhaps they want a website, or they want to have a good place to manage their mail. But in general, the last thing they want is to learn how to ssh into the server to change their password.
So, for most of them, they just use whatever password I set up for them.
One of my friends, who just began using mail on the server, was surprised that it was not convenient to change his password. That spurred me to address the long standing problem. How to let people manage their password for access to services.
The blog now has a new menu on the left, for access to the backend, and for linking to the reset-password screen. There is also a reset password link on the login page https://wmbuck.net/index/login.
The same password is used for all the wmbuck.net stuff: the password for access to mail, the password to get access to protected websites in apache, and the password for logging in to the wmbuck.net backend website.
Continue reading Managing passwords on this server

Using pam_mysql for authentication

On the occasion of moving the server to amazon, I decided to stop using LDAP. I was making very little use of it, having started to keep my contacts elsewhere. All it was really doing was providing the authentication file for apache logins. And there were so few of those it was quite easy to manage with an htpasswd file.

But recently I’ve begun providing mail to some friends, and while I am happy to provide them with system accounts the problem is that they don’t really WANT system accounts – they just want mail. So the husband asked me, how do I change my password? And the only answer I have is, you have to log on. Worse than that of course, I can’t really even allow him to log on without making him set up for public key authentication.

I would like to enable people to use the server for mail, and to be able to authenticate with apache, and I would like them to manage their own passwords for this, without making them log on via ssh, which would require that they have a key pair registered with me. I looked into being able to change the system password via a webpage, but it looks very messy, and seriously – system passwords are supposed to require a human being – that is intentional.

So I looked into authenticating the mail, and apache, using a database. I found a pam module called pam_mysql which I can use with saslauthd. I set /etc/pam.d/imap and smtp to point to a new pam entry called mail, which uses pam.mysql to autheticate against the database (and still also authenticate against system accounts as well if there is no entry in the database).
Continue reading Using pam_mysql for authentication

Boinc client: No usable GPUs

The first thing I had to do to get this to work was to obtain the updates for GPUs, for ubuntu this was boinc-amd-opencl.

Then I had to add into /etc/init.d/boinc-client the xhost command, which would give access to the GPU to the boinc username.

The information on the web was wrong about this. The command I had to add was:

xhost si:localuser:boinc

si means server interpreted, and the kinds of strings accepted are described in man xsecurity. Localuser implies a local username. The web articles I found claimed one needed to do xhost local:boinc, but the description of xhost:local is that it doesn’t take a username, and it makes LOCAL connections available. Which sounds good, but didn’t work. After doing xhost local:boinc it was the same as if I had just done xhost local, and I got an entry “LOCAL” when I did xhost, but it didn’t work.

Apache Configuration Issues

Trying to set up a new Zend Framework (ZF) website, I struggled once again with getting the setup correct. I learned some lessons, and this post is supposed to help me remember them.

First, the requirements.

1) ZF websites need rewrite rules to force all the urls through index.php so the can be picked apart. Also, ZF websites using the ZF config mechanisms need an APPLICATION_ENV php variable set somewhere in the site configuration, so the website can figure out where it is running and make hosting specific decisions (like, e.g. where the database will be, whether to turn on debugging, etc.).

2) I want to keep the website in a repository, and check it out onto different web-hosts  for testing, development, production. So any configuration stuff which is web-host specific should not be in the repository but in the host configuration files.

3) Although the urls for the ZF website need to be rewritten to index.php, there may be other urls (like phpmyadmin) that should not be rewritten. So the configuration has to allow for this. In particular on some websites (like wmbuck.net) the website itself redirects non-logged in users to the blog (this blog) with a redirect to /blog/. The rules need to allow normal handling of this url (to select /blog/index.php) in the normal way.

The rewrite rules and application environment stuff can be put in an .htaccess file within the DocumentRoot. Most ZF documentation describes doing it this way. But for me, at least the application environment variable can’t be here because everything under DocumentRoot is in the repository. So I want APPLICATION_ENV oregano on one box, APPLICATION_ENV tarragon on another box, and if I put this in .htaccess, and .htaccess is in the repository the file can only have one or the other setting.
Continue reading Apache Configuration Issues

New Server

The server for wmbuck.net (tarragon is its name) has been moved to Amazon EC2.

In part this was an experiment, motivated by curiosity about the ease or difficulty of maintaining a server in the cloud. But also in part it was motivated by dissatisfaction with the previous hosting environment, superb hosting. I needed to upgrade the server capacity. It had not been improved for 7 years, and it was ancient hardware when I got it. But at superb I ran into a lot of trouble, because I wanted to use btrfs (see earlier post  about using btrfs on the home computer, oregano). Superb offers old stable kernels, but I really  needed a kernel new enough to have a stable btrfs in it. After I lost all my work owing to btrfs driver problems in an old CentOS kernel, I was highly motivated to try another hosting arrangement where I could have my kernel of choice.

In mid May I set about creating a new tarragon. It took less than a week to set up, including all my learning curve, and all the migration issues, data transfer, etc. It has been running as wmbuck.net for over a month. The few hiccups were mistakes of transition on my part. Up to this moment I have had no problem which has turned out to be of any but my own making.
Continue reading New Server

New disk layout using btrfs

Preparatory to doing an upgrade of Fedora on one of my linux boxes, I decided it was time to revise the disk layouts. Specifically, I finally got around to building a separate partition for /home. After doing a little reading, it looked to me like a good way to do this was to use btrfs. Initially I also made a separate /var, but decided that was both unneeded and error prone, and went another way. The main objective of this work was to reduce the drag in upgrading Fedora.

Root is on a small (64GB) SSD, LUKS encrypted which has /boot and an LVM VG for / and swap. / is ext4. I built a 2GB mdadm raid-1 mirror with LUKS encryption on top of it, and then layered a btrfs file system on that called oreganodata. The root of oreganodata is not typically mounted, but has the following subvolumes automounted at boot time:

  1. /home -> oreganodata/home
  2. /mail->oreganodata/mail,  /var/lib/imap and /var/spool/imap symlink to the /mail/lib and /mail/spool directories.
  3. /var/lib/mysql->oreganodata/maria
  4. /usr/local/bin->oreganodata/bin
  5. /etc/pki/mycerts->oreganodata/certs
  6. /var/webdata->oreganodata/webdata (websites have symlinks to /var/webdata as needed)

Continue reading New disk layout using btrfs

Boot Disk Encryption, Cryptsetup and Initramfs

Setting up Cinnamon so that the boot disk is encrypted has been a source of frustration for 3 releases now.

Most recently I installed Saucy. As with Roaring it doesn’t seem to be possible to install onto an encrypted root successfully with the desktop installer. Everything seemed to work until it was time to install the boot loader. That seems to have failed and I wasn’t able to get it to work.

Ultimately, I went back to installing the server version, and then doing an apt-get install ubuntu-desktop. Although this seemed to work out of the chute, I had a few issues.

The configuration files for lightdm changed structure, and my “after the reinstall script” which endeavours to restore all the tweaks I have in config files, put a file named /etc/lightdm/lightdm.conf out there, which seemed to croak lightdm. When I moved the file into the new lightdm.conf.d scheme that problem was solved. All that was about getting synergy client running as soon as the display manager comes up.
Continue reading Boot Disk Encryption, Cryptsetup and Initramfs

Getting tomcat running again

It has been a hell of a struggle to upgrade the server (which hosts this site) from Fedora 13 to Fedora 17. The last step was to get my flying apps running in Tomcat again. I confess I don’t track what happens in the java world very closely. And it is a very active world – lots of stuff happening. So it is no surprise I suppose that when you jump four releases there are some adjustments to be made.

To get tomcat running I had to make the following adjustments, in addition to the obvious stuff of adding the FlightPlan war file to /usr/share/tomcat/webapps, installing the mysql jdbc connector, and updating /etc/tomcat/tomcat-users.xml.

Tomcat was unable to find org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory. I had to add:  JAVA_OPTS=”$JAVA_OPTS -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory” in /etc/sysconfig/tomcat. It may be that this is a problem of my own making somehow. In an earlier post I commented about the ongoing evolution in the methods available to connect java apps/servlets with databases. My servlets now use java Datasources, which I think are the “latest thing”, and I’m a little surprised that I have to make special provision for finding the classes. This makes me think it probable that if I understood this better, and did things according to “best practice” in the java world, I wouldn’t have this problem. But as I said before, catching up with all the advancements in java over 7 years is a tall order.

Then Tomcat was unable to find apache-commons-pool.jar, so I had to add a symlink: commons-pool.jar -> /usr/share/java/apache-commons-pool.jar in /usr/share/tomcat/lib. This is less surprising I think. The reference to this part of apache commons is coming from the previous (BasicDataSourceFactory) classes. If the former aren’t there, we don’t need this.

The flying apps seem to be running properly now.

Authentication, LDAP, phpMyAdmin

I’ve had a long standing problem. Every time I rebuild my main server (which contains my websites, my mail, my ldap directory, etc), I get myself wrapped around the axle with authentication. I particularly seem to get into trouble with authenticating access to phpMyAdmin. I use ldap for basic authentication in apache. This morning I figured out some obvious things (they are always obvious once you figure them out). I write this down so that the next time I make the same mistake, I’ll have someplace to look to trigger my memory. If it should happen that anyone else who suffers from the same density could get any help from this, so much the better.

Continue reading Authentication, LDAP, phpMyAdmin