Dungeons & Dragons

I played 5th edition D&D Starter Kit last night with my gaming group.  It was really good.  We were first level, there were goblins and it felt *right*.  It was probably helped by a little real ale and the decision to switch to candlelight half way through.  In fact, candlelight was a revelation for me - previously I have only ever employed it in horror games, but last night I realised that I perform better as a player when I don't feel I'm under a harsh light.

NAS disabling sshd on a reboot

Having got SSHD configured on my D-link DNS-320 NAS successfully (and outlining the process in my last post) the setup has somehow reset itself. This is behaviour I thought I'd seen before a while back, but had put it down to a slip up on my part. Delving further it turns out this isn't just affecting SSHD - I installed an SVN server on the NAS the other day and the SVN daemon config files have also mysteriously reverted to their default contents (and possibly permissions).

With the kid in bed and the baby drifting off with a bottle (held by wife) I decided I'd sit down and try to crack this nut. Taking stock first, it turns out that the permissions on the following files have reverted to the fun_plug defaults:

/ffp/home/root directory (permissions should be 755)
/ffp/home/root/.ssh directory (should be 700)
/ffp/home/root/.ssh/authorized_keys (should be 600)
/ffp/etc/ssh/* contents (should be 600)
/ffp/var/lib/sshd (700 will do)

After setting these all to the right perms I rebooted the NAS (using the 'reboot' command from a telnet session). Lo and behold, I can subsequently no longer establish a SSH session to the NAS.

/ffp/home/root has reverted to 777
/ffp/home/root/.ssh has reverted to 722
/ffp/home/root/.ssh/authorized_keys has reverted to 622
/ffp/etc/ssh/* has reverted to 622
/ffp/var/lib/sshd has reverted to 622

So there are the symptoms. Question is, what's the cause? It sounds like it might be down to a feature of the D-Link firmware. I can understand how brute-force setting of permissions might help keep the system stable for non-fun_plug users, but what a bummer for me. Now trying to reset the NAS to factory settings... no improvement. I give in.

Getting public-key SSH login to my NAS working

Here are notes on what I had to do to make it work.

Create an RSA-style public/private key pair on the client.

ssh-keygen -t rsa

Then follow the simple instructions here to tell the NAS that the client's public-key is an authorised user.

On the NAS, set the home directory of the user I want to connect as to the following.
chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*

Ensure that the SSH daemon on the NAS is set to allow the right sort of connections (this was set by default in fun_plug 0.7).

RSAAuthentication yes
PubkeyAuthentication yes

Ensure that the home directories on the client and NAS have the correct permissions set

chmod 755 /home/xxx


But if doesn't end here! Unfortunately, after rebooting the NAS fun_plug changes the permissions on the files in /ffp/etc/ssh which in turn prevents the SSH daemon from starting properly.  Fixed this with the command

chmod 600 /ffp/etc/ssh/*
But then I found that it has set the permissions of the /ffp/var/lib/sshd file to be too wide. It needs to be owned by root and not group or world writable. So I had to run the following. chmod g-w /ffp/var/lib/sshd
chmod o-w /ffp/var/lib/sshd

I need to add these permissions to the fun_plug startup script. I also could do with learning how to work out the numeric permission values that can be passed to chmod (at the moment I'm just finding them on some blog or other and blindly typing them in!).

Awful things that people say in my company

I work for a big (multinational) software company.  Most of the managers there regularly use words like smarts, cadence and on-boarding (ugh).   I'm a manager too but I won't go anywhere near words like these.  It seems like the higher up the management chain you go, the more likely you are to use them.

It's important to me to maintain the respect of my team and I just don't think you can do that when you throw these sorts of words around.  They're cheesy and false and I'm frustrated to see people who I once respected adopting them.  Now I have to try very hard not to hate them.

Why can't people just say what they mean using all the perfectly adequate words we already have in the English language?  Don't they realise that they sound like corporate tools and thereby distance themselves from their staff?

Word of the day: kanban

Two for one! I just got excited about kanban. I can see how it could be really satisfying to use at work for developing software (increasingly I'm less sure that Scrum really fits how we work). I also have an inkling I can borrow some concepts to make a rather spiffing table-top RPG (you'd play on a kind of graded - or stepped - board which you can use figures on, but it's not a map!).

I Manage

I manage people for a living. That is to say, I do other things too (like programming and writing specs) but my key responsibility to is to drive, guide and support other people so that they can write software.

So far, apart from the very occasional management course, I've winged it. I've got by on my natural charm, persuasiveness and mediatory talents, such as they are. I'd like to do better though - provide a better work environment for my team so they can do the things they need to do more effectively. To that end, I think a natural tendency is to introduce process and, in software development at least, that tends to mean acquiring or writing workflow tools. I've done it myself over the last few months, attempting to maintain consistency and control over a largish new team. But now I'm ready to attack that process, pare it back, scrutinise it harshly to see which procedures are really necessary. What is their effect on my developers.

Here are some things I've read recently that have gone up my flag-pole:

[The] main reason people make the trek to your office is because they need conflict resolution. Once the conflict participants stop yelling, you need to get them looking at facts because facts will ground them and grounded means less yelling. Rands In Repose

This interests me. It's analogous to what the ScrumMaster is for in a Daily Scrum: oiling the wheels. A ScrumMaster resolves blockages, a manager resolves conflicts.

The Best Software Writing

I've been reading The Best Software Writing 1 which is a collection of interesting articles written by forward thinking people in the world of programming. They've been selected and each one introduced by Joel Spolsky and I've found it a good read. And that's the USP (unique selling point) of the book: it's written by programmers and it's also written with panache Over my next few posts I'll be talking a bit about ideas I've read in this book.