EvanK's questions

I have a recently installed Ubuntu (natty) server, with a domain pointed to it. The mail for this domain is handled by Google Apps (via MX dns records pointing to Google's mail servers).

Now, I've installed logcheck, and am periodically getting emails (via logcheck) about the following log entries:

Jun 17 15:02:06 nattybox sm-mta[26023]: STARTTLS=client, relay=aspmx.l.google.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128
Jun 17 13:02:07 nattybox sm-mta[8533]: STARTTLS=client, relay=aspmx.l.google.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128
Jun 17 13:17:45 nattybox sm-mta[10465]: STARTTLS=client, relay=aspmx.l.google.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128
Jun 17 13:51:56 nattybox sm-mta[14995]: STARTTLS=client, relay=aspmx.l.google.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128
Jun 17 12:02:06 nattybox sm-mta[32143]: STARTTLS=client, relay=aspmx.l.google.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128

It looks like sendmail is trying to use the google mail servers as a relay, which I guess is failing? I installed sendmail via aptitude, and am using the configuration files that came with it. To be clear, sendmail seems to be working in that messages sent from this server get delivered just fine.

Are the above log messages something I should be concerned about, and if so, how would I go about fixing it?

I'm writing an lsb init script (admittedly something I've never done from scratch) that launches a php script that daemonizes itself. The php script starts off like so:

#!/usr/bin/env php
<?php
/* do some stuff */

It's then started like so in the init script:

# first line is args to start-stop-daemon, second line is args to php-script
start-stop-daemon --start --exec /path/to/executable/php-script.php \
  -- --daemon --pid-file=$PIDFILE --other-php-script-args

The --daemon flag causes the php script to detach & run as a daemon itself, rather than relying on start-stop-daemon to detach it.

This is how it's (trying to) stop it in the init script:

start-stop-daemon --stop --oknodo --exec /path/to/executable/php-script.php \
  --pidfile $PIDFILE

The problem is, when I try to stop via the init script, it gives me this:

$ sudo /etc/init.d/my-lsb-init-script stop
 * Stopping My Project
No /path/to/executable/php-script.php found running; none killed.
   ...done.

A quick peek at ps tells me that, even though the php script itself is executable, its running as php <script> rather than the script name itself, which is keeping start-stop-daemon from seeing it. The PID file is even being generated, but it seems to ignore it and try to find+kill by process name instead.

$ ps ax | grep '/path/to/executable/php-script.php'
 2505 pts/1    S      0:01 php /path/to/executable/php-script.php --daemon --pid-file /var/run/blah/blah.pid --other-php-script-args
 2507 pts/1    S      0:00 php /path/to/executable/php-script.php --daemon --pid-file /var/run/blah/blah.pid --other-php-script-args
 2508 pts/1    S      0:00 php /path/to/executable/php-script.php --daemon --pid-file /var/run/blah/blah.pid --other-php-script-args
 2509 pts/1    S      0:00 php /path/to/executable/php-script.php --daemon --pid-file /var/run/blah/blah.pid --other-php-script-args
 2518 pts/1    S      0:01 php /path/to/executable/php-script.php --daemon --pid-file /var/run/blah/blah.pid --other-php-script-args
$ cat /var/run/blah/blah.pid
2518

Am I completely misunderstanding something here? Or is there an easy way to work around this?

I just updated my kernel on an Ubuntu 9.10 system from 2.6.32.1 to 2.6.33.5, and everything seemed to go well, except now my system log is getting flooded with errors from getty:

Jul 25 11:01:54 kobol getty[2414]: /dev/tty4: cannot open as standard input: No such device
Jul 25 11:01:54 kobol getty[2415]: /dev/tty2: cannot open as standard input: No such device
Jul 25 11:01:54 kobol getty[2416]: /dev/tty6: cannot open as standard input: No such device
Jul 25 11:01:54 kobol getty[2417]: /dev/tty3: cannot open as standard input: No such device
Jul 25 11:01:54 kobol getty[2418]: /dev/tty5: cannot open as standard input: No such device
Jul 25 11:01:54 kobol init: tty4 main process (2409) terminated with status 1
Jul 25 11:01:54 kobol init: tty4 main process ended, respawning
Jul 25 11:01:54 kobol init: tty2 main process (2410) terminated with status 1
Jul 25 11:01:54 kobol init: tty2 main process ended, respawning
Jul 25 11:01:54 kobol init: tty6 main process (2411) terminated with status 1
Jul 25 11:01:54 kobol init: tty6 main process ended, respawning
Jul 25 11:01:54 kobol init: tty3 main process (2412) terminated with status 1
Jul 25 11:01:54 kobol init: tty3 main process ended, respawning
Jul 25 11:01:54 kobol init: tty5 main process (2413) terminated with status 1
Jul 25 11:01:54 kobol init: tty5 main process ended, respawning

Any idea what is causing this and how to get it to stop? I realize its not a critical issue, but it's still annoying that it's constantly happening (and filling up log files) and I don't know why.

UPDATE: This is the listing for my tty devices, the permissions of which seem to be reset on reboot

crw------- 1 root root 4, 0 2010-07-26 10:00 /dev/tty1
crw--w---- 1 root tty  4, 1 2010-07-26 10:00 /dev/tty2
crw--w---- 1 root tty  4, 2 2010-07-26 10:00 /dev/tty3
crw--w---- 1 root tty  4, 3 2010-07-26 10:00 /dev/tty4
crw--w---- 1 root tty  4, 4 2010-07-26 10:00 /dev/tty5
crw--w---- 1 root tty  4, 5 2010-07-26 10:00 /dev/tty6
crw--w---- 1 root tty  4, 6 2010-07-26 10:00 /dev/tty7
crw--w---- 1 root tty  4, 7 2010-07-26 10:00 /dev/tty8

And the init script for tty1:

# tty1 - getty
#
# This service maintains a getty on tty1 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]

respawn
exec /sbin/getty -8 38400 tty1

And the (practically identical) init scripts for tty2-tty6:

# tty2 - getty
#
# This service maintains a getty on tty2 from the point the system is
# started until it is shut down again.

start on runlevel [23]
stop on runlevel [!23]

respawn
exec /sbin/getty -8 38400 tty2

UPDATE 2: Permissions for the init scripts follow...

-rw-r--r-- 1 root root 228 2009-12-10 11:00 /etc/init/tty1.conf
-rw-r--r-- 1 root root 213 2009-12-10 11:00 /etc/init/tty2.conf
-rw-r--r-- 1 root root 213 2009-12-10 11:00 /etc/init/tty3.conf
-rw-r--r-- 1 root root 213 2009-12-10 11:00 /etc/init/tty4.conf
-rw-r--r-- 1 root root 213 2009-12-10 11:00 /etc/init/tty5.conf
-rw-r--r-- 1 root root 213 2009-12-10 11:00 /etc/init/tty6.conf

A grep of running getty instances shows this:

$ ps auxww|grep [g]etty
root      2228  0.0  0.2   5992   604 ?        Ss+  10:00   0:00 /sbin/getty -8 38400 tty1
root      6352  0.8  0.2   5988   688 ?        Ss   11:06   0:00 /sbin/getty -8 38400 tty3
root      6355  0.5  0.2   5988   684 ?        Ss   11:06   0:00 /sbin/getty -8 38400 tty4
root      6356  0.5  0.2   5988   684 ?        Ss   11:06   0:00 /sbin/getty -8 38400 tty6
root      6357  0.8  0.2   5988   684 ?        Ss   11:06   0:00 /sbin/getty -8 38400 tty2
root      6358  0.6  0.2   5988   684 ?        Ss   11:06   0:00 /sbin/getty -8 38400 tty5

UPDATE 3: After downgrading to 2.6.32.1 the errors disappeared. I recently upgraded again to 2.6.34.1 and they showed up again. I'm superbly baffled now.

We have an Ubuntu 9.04 server running samba with null passwords and home directory shares, and we have corresponding users that mount said shares on windows machines. Essentially, each user has an account on the server (with the same username as on their windows machines) and a home directory in /home/USERNAME which is mounted on their local machine as \\SAMBABOX\USERNAME which they then have full access to.

For most users this works without a problem; they can read, write, create, and delete files on their shares without issue. Following is one such initial connection as seen in the samba logs:

[2009/12/02 10:30:22,  1] smbd/service.c:make_connection_snum(1115)
  somewindowsbox (192.168.2.123) connect to service ekaufman initially as user ekaufman (uid=1002, gid=1002) (pid 22574)

For one user in particular, however, they are unable to - at the very least - create certain files (lock files for an SVN working copy). This is, mind you, from any windows machine in our AD domain. Looking at their samba logs, their initial connection is made as the user nobody, and I cannot for the life of me figure out why.

[2009/11/18 10:19:32,  1] smbd/service.c:make_connection_snum(1115)
  somewindowsbox (192.168.2.123) connect to service jdoe initially as user nobody (uid=65534, gid=65534) (pid 15570)

Their user account on the ubuntu server is more or less identical to the others, as indicated in /etc/passwd:

ekaufman:x:1002:1002:,,,:/home/ekaufman:/bin/bash
jdoe:x:1015:1015:,,,:/home/jdoe:/bin/bash

And /etc/group:

ekaufman:x:1002:
jdoe:x:1015:

And even /etc/shadow (with the password hashes removed before being posted here, of course):

ekaufman:!:14580:0:99999:7:::
jdoe:!:14572:0:99999:7:::

I've even deleted their account on the ubuntu box and recreated it, with no change. According to the admin of the AD domain controller, their account there is more or less identical to everyone elses as well (deleting and recreating it there would be prohibitively complicated).

If I manually mount the share for my own account from a windows machine, forcing the username, it works without incident:

C:\> net use z: \\sambabox.local\ekaufman /user:ekaufman
The command was completed successfully

If I do the same for this particular user, it still connects as nobody, failing silently:

C:\> net use z: \\sambabox.local\jdoe  /user:jdoe
The command was completed successfully

This gives me the impression that, whatever the problem is, it's on the linux side of things.

This is the entire smb configuration in use:

[global]
   null passwords = yes
   guest ok = yes
   security = user
   workgroup = WORKGROUP
   server string = %h server (Samba, Ubuntu)
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   usershare allow guests = yes

[homes]
   comment = Home Directories
   browseable = no
   read only = no

[printers]
   comment = All Printers
   browseable = no
   path = /var/spool/samba
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700

[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no

I have a group of linux apache 1.3 servers behind a load balancer, and I want to be able to, at a glance, determine which server I'm hitting. The load balancer is severely limited in its monitoring capabilities, so what I'd like to do is configure apache to send an additional header indicating the machine's hostname.

I know I could just hard-code a header into the httpd.conf with the hostname:

Header set X-Which-Host-Am-I 'host1'

However, all the servers in question are mirrored with rsync, including the configs, so hard-coding the hostnames is out. Is there a way I can call the hostname command and dump it into a header?

Clarification: Since multiple virtual hosts live on these servers, I want the physical machine's hostname, not the domain name in the request.