$ apt-get source mysql-server .... [will download the source and apply the diffgz etc] .... $ cd mysql-dfsg-5.0-5.0.1a $ patch -p1 < /path/to/mysql-dfsg-5.0_5.0.51a-3ubuntu5-sphinx1.debdiff .... [messages about files patched] .... $ dpkg-buildpackage -rfakeroot -us -uc .... [builds and unsigned package. Takes *really* long] ....update: It turns out that the MySQL error messages didn't change after all. I should have noticed earlier, but the difference in error messages is because the build machine was using OpenDNS, which wasn't returning a NXDOMAIN for invalid/nonexistent hosts. The debdiff is now fixed and the unnecessary dpatch has been removed. But the thing to learn from this is that if your build machine is using OpenDNS in its default configuration (it's possible to fix OpenDNS' behaviour) - the MySQL test suite *WILL FAIL*.]]>
when logging in via ssh, the ssh daemon checks some files in ~/, so it can be done if the user already have a valid home directory.from this thread.
The real reason why it doesn't successfully authenticate is because ssh does a getpwent() call to check if the user exists on the system. If you're using just a PAM solution (which doesn't provide accounts), that call fails if there isn't any such local user. sshd then sets the password to '^H ^M INCORRECT' before passing it to PAM, which obviously thinks it's the wrong password. The simple (and probably unscalable - but then you should be using something like nss_mysql) solution is to add local accounts to the machines for these users. That will make the getpwent() call succeed, and sshd will authenticate successfully via PAM.
I've mentioned this earlier.
]]>First, there's the /etc/network/interfaces file :
# we always want the loopback auto lo iface lo inet loopback # mappings mapping eth0 script /etc/network/map-scheme map dhcp eth0-dhcp map emergency eth0-emergency mapping ath0 script /etc/network/map-scheme map office ath0-office map home ath0-home iface eth0-dhcp inet dhcp up iptables -F up lokkit -n -q --high --dhcp up /etc/init.d/lokkit restart iface ath0-office inet dhcp wpa-driver madwifi wpa-conf /etc/wpa_supplicant/office.conf up iptables -F up lokkit -n -q --high --dhcp up /etc/init.d/lokkit restart iface eth0-emergency inet static address 10.9.5.201 gateway 10.9.4.1 netmask 255.255.254.0 up iptables -F up lokkit -q --high up echo nameserver 172.31.6.5 > /etc/resolv.conf up echo nameserver 203.197.12.30 >> /etc/resolv.conf iface ath0-home inet dhcp wpa-driver madwifi wpa-conf /etc/wpa_supplicant/home.conf up iptables -F up lokkit -n -q --high --dhcp up /etc/init.d/lokkit restart
Notice the mappings section (and see 'man interfaces') - that allows me to say :
NETSCHEME="home" sudo ifup ath0
or
NETSCHEME="office" sudo ifup ath0
because the specified script (/etc/network/map-scheme) just looks up the NETSCHEME environment variable and spit out the correct mapping to go to. This thing, by the way, could be rigged to do arbitrarily complex tasks (look in /usr/share/doc/ifupdown/examples/ for sample scripts, including one which tries to ping some known IPs, and decides its location/profile based on successful pings - you could write one which looks for all known wireless SSIDs and then decide which profile to switch to). Here's my trivial script :
#!/usr/bin/perl -w
use strict;
my $scheme = $ENV{NETSCHEME} || "home";
while(<>) {
if ( s/$scheme\s+// ) {
print;
}
}
The conf files in /etc/wpa_supplicant/* are of course wpa_supplicant configuration files. See 'man wpa_supplicant.conf' for details.
]]>