You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Troubleshooting myself in the foot.

Category: configs

Those pesky config files.

Java update causing ubuntu installer to fail

On trying to install the Oracle JDK on ubuntu 16.04 I kept getting ERROR 404: Not Found. After some searching I found out that the problem is that there is a new version of java and the installer (which is essentially a wrapper around the Oracle installer) wasn’t updated to reference it.

Since I needed this not as an update, but an install (and I just wanted to know why it was broken), I ended up updating some configs (with the help of pointers from a SO article).

To fix it on ubuntu x64 you need to sub out the file name, URL and checksum for the old version (191) with the new version (201).

cd /var/lib/dpkg/info
sed -i 's|JAVA_VERSION=8u191|JAVA_VERSION=8u201|' oracle-java8-installer.*
sed -i 's|PARTNER_URL=|PARTNER_URL=|' oracle-java8-installer.*
sed -i 's|SHA256SUM_TGZ="53c29507e2405a7ffdbba627e6d64856089b094867479edc5ede4105c1da0d65"|SHA256SUM_TGZ="cb700cc0ac3ddc728a567c350881ce7e25118eaf7ca97ca9705d4580c506e370"|' oracle-java8-installer.*
sed -i 's|J_DIR=jdk1.8.0_191|J_DIR=jdk1.8.0_201|' oracle-java8-installer.*

After that, rerun apt-get update, apt-get install oracle-java8-installer and you are set to go.

fios blocks outbound smtp. gah! danger, danger – port 25

FIOS blocks outbound SMTP, and I’m fairly comfortable saying every household ISP should. However, you can use their outbound SMTP servers as a relay to get around this. I had to configure this last night with postfix and I have to say it was trivial to set up.

I ended up inserting this to my postfix

relayhost = []
smtp_connection_cache_destinations =
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps =
smtp_sasl_security_options = noanonymous
default_destination_concurrency_limit = 4
soft_bounce = yes

Thanks to Jason Haruska for the pointers.

Restart postfix, test (man postfix| mail root -s “some light reading for you”) and requeue all the borked messages (postsuper -r ALL) and you are on your way.

I mentioned this to some of my geeky counterparts and they looked at me and said “Oh, yeah, that rocks, I did that a ways back with Exim.”  It seems its even easier with exim, you just need to add your username and password to /etc/exim4/passwd.client.  For full instructions on how to do this, check out the gmail/exim page.

My pain your sent mail (I lie, this was not so much of a pain, rather fun).

autofs annoyances with ubuntu lucid (10.04)

Like a lot of admins that run ubuntu, we decided to update many of our machines to ubuntu’s next LTS release, lucid lynx, aka ubuntu 10.04.  We dont run a huge shop here, we have under 100 machines, a significant percentage of which are VMs, but repeatedly fixing bugs does still annoy me.  One of the bugs present in lucid is particularly annoying because it affects how autofs starts at boot.  Services have dependencies, and its complicated to sort them out – I get that – but come on ubuntu, dependencies are not a new development and sorting them out should be easy enough for a bunch of smart developers.

The specifics are this:

1. Lucid switched to upstart.  To put it succinctly: “upstart is a replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running.”

2. Upstart does not like autofs.

Not to rant too much, but if you are going to replace init, please do it with something that does not require that every person installing various packages has to do the hacks I am about to point out.

Thankfully, there are a bunch of smart, technical people that run ubuntu systems.  On top of that, when things go wrong they complain and post bug reports.  After some quick searching I thought I had fixed the bug.  That was until upstart was updated a couple of weeks back and the boot problems started again with autofs.

The solution is similar to the one I originally implemented, per the suggestion of comment #15, but it works past the update that had broken autofs again.  In the /etc/init directory edit the autofs.conf file and add the following stanza directly after the pre-start script line.

statd_status=`status statd| cut -d, -f1`
while [ "$statd_status" != "statd start/running" ]; do
sleep 5
start statd
let i++; statd_status=`status statd| cut -d, -f1`
if [ $i -gt 10 ]; then
echo "statd startup failed"

Once this is in you should be able to (re)start autofs.  Next time the machine is rebooted, autofs will have been started automatically.  Essentially this is the same hack as the one in the aforementioned comment, with the exception that the while loop causes the script to wait until it sees statd has successfully started.

Ok, back to finding more annoying things.

PAM configurations

Ok, so this one did not take me hours, but I did have to go read a manual because no one seems to explain these settings – everyone just says “hey! these settings worked for me, plug em in.” That was my cue to try and understand it better.

Turns out that the Linux PAM system administrators guide was not really that bad and had some very useful explanations of how things work.

One thing I was looking to find out what the new bracket “[]” syntax for PAM config files works. Most admins will probably have seen this example somewhere:

auth [success=1 default=ignore]
auth required try_first_pass
auth required

What is up with those brackets? Turns out its pretty simple. According to the docs, the value=action control values are just a way of telling PAM what to do with the result of the rule (In this case, the rule is go check and tell me what it said).

The value for the control can be set to any of the return values of the rule – success being rather obvious, default meaning anything that I didnt explicitly write. The action for the control can be ignore, bad, die, ok, done, reset or a number – the number just means skip the next N rules (the PAM SAG explains the config syntax fully).

In the above case, PAM is being instructed, in the common-auth config file to check LDAP first, ignore its failure if it cant find a username:password pair in the directory, or skip the next rule if it does find the pair. If it fails, it falls back to local accounts, if it succeeds iit jumps to the rule which just permits anything it gets (keep in mind that if any required rule fails, the whole block fails, so thats why cant permit something that fails).

Thats it – pretty thought out by those clever PAM people. I hope I’ve explained it well enough here to help out. For a more in depth read, check out the Linux PAM system administrators guide.

My – aww man, do I really have to read this manual – pain, your gain.

© 2023 My pain, your gain.

Theme by Anders NorenUp ↑