This is pretty incredible but totally what you’d expect from somebody like him
I’ve been setting users passwords successfully on CentOS/RHEL from within my kickstarts, using entries like this:
echo p4ssw0rd | passwd --stdin username
… however, that unfortunately doesn’t work on at least Ubuntu (and possibly many other distros as well).
Now — finally — and thanks to this comment, I have an answer; and it looks something like this:
echo username:password | chpasswd
(Note that I’ve only ever done this on CentOS 6.2. It should work in a lot of other places too though, especially other RHEL based distros.)
I really wanted to use the Smokeping init script that comes with Ubuntu 10.04.* LTS on a CentOS 6.2 box. One look at it, however, and you will very quickly realise that out-the-box that isn’t something which is likely to work, possibly for other reasons, but definitely because you don’t have “start-stop-daemon” on a CentOS box; not yet at least
This helpful post suggested that if you pull the dpkg source from one of the Debian mirrors then you could build it, albeit quite nastily, and end up with a successful build of start-stop-daemon. However, it doesn’t have to build so nastily. Newer versions of dpkg build cleanly, as I discovered and have detailed below. As root or using sudo, do the following:
wget -c "http://za.archive.ubuntu.com/ubuntu/pool/main/d/dpkg/dpkg_18.104.22.168ubuntu3.tar.bz2"
tar jfxvh dpkg_22.214.171.124ubuntu3.tar.bz2
./configure --without-install-info --without-update-alternatives --without-dselect
make && make install
Now if you type “which start-stop-daemon” you should discover that it’s built and installed into /usr/local/sbin, and works perfectly just like it’s supposed to. And with that hurdle out the way, I could now finish getting that Ubuntu init script working on CentOS. Happy time
Sorry, this is a bit lazy of me, but at the moment I can only confirm that this works on Ubuntu 10.04.4 LTS. It might, however, work on other versions too, and maybe also with Debian of course.
If when you run an apt-get update you are being told something like this right at the end:
W: GPG error: http://196.x.y.z lucid Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 2940ABA983EF826A
… then install “add-apt-key” on the box, and run it, adding the missing key itself to the end of the command, as shown below.
root@xyz-box-bry-01:~# apt-get install add-apt-key Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: add-apt-key 0 upgraded, 1 newly installed, 0 to remove and 5 not upgraded. Need to get 5,314B of archives. After this operation, 81.9kB of additional disk space will be used. Get:1 http://196.x.y.z/ubuntu/ lucid/universe add-apt-key 1.0-0.5 [5,314B] Fetched 5,314B in 0s (270kB/s) Selecting previously deselected package add-apt-key. (Reading database ... 88896 files and directories currently installed.) Unpacking add-apt-key (from .../add-apt-key_1.0-0.5_all.deb) ... Processing triggers for man-db ... Setting up add-apt-key (1.0-0.5) ... root@xyz-box-bry-01:~# add-apt-key 2940ABA983EF826A gpg: directory `/root/.gnupg' created gpg: new configuration file `/root/.gnupg/gpg.conf' created gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/root/.gnupg/secring.gpg' created gpg: keyring `/root/.gnupg/pubring.gpg' created gpg: requesting key 83EF826A from hkp server subkeys.pgp.net gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 83EF826A: public key "Opscode Packages " imported gpg: Total number processed: 1 gpg: imported: 1 OK root@xyz-box-bry-01:~#
I’ve found that sometimes the key server doesn’t have the key and so it’s not imported, but re-running the command generally fixes that as the next key server chosen usually does end up having the key. Once you’ve successfully imported the key, run “apt-get update” again and your problem should no longer exist.
There was something else I wanted to say but I’ve totally forgotten what it was.
I wonder if this dude still lived his life convinced that he’d be caught up with any minute.
This is pretty crazy!
“DENVER (AP) — Two men are accused of driving around with a dead friend, using his ATM card and visiting a strip club in a less amusing real-life version of the film ‘Weekend at Bernie’s.’”
Wow, this is an awesome story about the mission during which /bin/laden was killed! Quite long though, and once you start reading it you won’t want to stop.