debian

On a fresh Debian 8 (Jessie) install, I found that I couldn't update the package repository using apt because security.debian.org was always timing out. While I initially thought this was because of a mirroring issue oslt, it turns out that it's because I was trying to access it via the IPV6 that my VPS was using. Turns out that the fix is reasonably straightforward. You simply tell apt not to bother with ipv6 and simply use ipv4 … like so:

echo 'Acquire::ForceIPv4 "true";' >> /etc/apt/apt.conf.d/99force-ipv4

I ran into the following error while running a script that was performing backups of files via rsync over ssh.

Setting the timezone of an Ubuntu (14.04, Trusty) or Debian (7, Wheezy) server from the command-line is simple. Just run dpkg-reconfigure tzdata and follow the on-screen prompts. However, if you are running an unattended installation, you might want to avoid interactive prompts and just gets the job done. To do this, simply run

Browse through /usr/share/zoneinfo/ to locate your timezone.

So, here I was writing a script that would automate the installation of a package in Ubuntu 14.04 and all was going swimmingly. Until I ran it. You know how some apt-get installs sometimes involve a technicolor pop-up that asks you for stuff? Well, those pop-ups interrupted my script which didn't proceed further. After much digging, I found that there are a couple of solutions for this:

On a new Ubuntu 14.04 (Trusty) LTS server, I ran into the following:

$ su -c /bin/bash foo
bash: cannot set terminal process group (3987): Inappropriate ioctl for device
bash: no job control in this shell

However, the su procedure worked and I was logged in as user foo.

I recently had trouble with a MySQL installation in Ubuntu. For some reason or the other, during an upgrade to a newer version of mysql-server, the upgrade script had issues stopping the server and the script failed. This meant that apt could no longer function as it kept raising a red flag over the broken upgrade with the following instructions:

This is my week of playing around with mail servers and I have been keeping an eye on the logs on a regular basis. I noticed that the auth.log was riddled with millions of these pointless (from my POV anyhow) log entries:

CRON: pam_unix(cron:session): session opened for user root by (uid=0)
CRON: pam_unix(cron:session): session closed for user root

While trying to debug a postfix authentication issue in Debian 6, I had to use testsaslauthd to test things out:
testsaslauthd -s smtp -u foo@example.com -p test

only to get the following error:
connect() : No such file or directory 0

This is apparently because a lot of people (and authors) follow the same guide for configuring postfix and saslauthd. One of the steps missing is to symlink and saslauthd directory to a location within postfix. To fix:

While setting up Drupal on a friend's Ubuntu server, I ran into the following error message:

This basically simply means that the PHP PDO extension has not been installed. It can be installed via something along the lines of:
sudo aptitude install php5-mysql

While you are at it, make sure that all the other PHP extensions that Drupal requires are also installed.

I just finished setting up postfix on a Debian 6 machine. All is peachy. However, when I checked my mail logs to see how things were going I noticed a number of entries for messages being sent from smmsp@example.com to root. Checking root's mail led to messages with the following content:
/usr/share/sendmail/sendmail: line 880: /usr/sbin/sendmail-msp: No such file or directory