Planet ALUG

Syndicate content
Planet ALUG -
Updated: 52 min 21 sec ago

Steve Engledow (stilvoid): Twofer

Wed, 16/09/2015 - 23:33

After toying with the idea for some time, I decided I'd try setting up 2FA on my laptop. As usual, the arch wiki had a nicely written article on setting up 2FA with the PAM module for Google Authenticator.

I followed the instructions for setting up 2FA for ssh and that worked seamlessly so I decided I'd then go the whole hog and enable the module in /etc/pam.d/system-auth which would mean I'd need it any time I had to login at all.

Adding the line:

auth sufficient

had the expected effect that I could login with just the verification code but that seems to defeat the point a little so I bit my lip and changed sufficient to required which would mean I'd need my password and the code on login.

I switched to another VT and went for it. It worked!

So then I rebooted.

And I couldn't log in.

After a couple of minutes to download an ISO to boot from using another machine, putting it on a USB stick, booting from it, and editing my system-auth file, I realised why:

auth required auth required try_first_pass nullok auth required unwrap

My home partition is encrypted and so the Google authenticator module obviously couldn't load my secret file until I'd already logged in.

I tried moving the line to the bottom of the auth group but that didn't work either.

How could this possibly go wrong...

So, the solution I came up with was to put the 2fa module into the session group. My understanding is that this will mean PAM will ask me to supply a verification code once per session which is fine by me; I don't want to have to put a code in every time I sudo anyway.

My question is, will my minor abuse of PAM bite me in the arse at any point? It seems to do what I expected, even if I log in through GDM.

Here's my current system-auth file:

#%PAM-1.0 auth required try_first_pass nullok auth required unwrap auth optional auth required account required account optional account required password optional password required try_first_pass nullok sha512 shadow password optional session required session required session optional unwrap session optional session required
Categories: LUG Community Blogs

Chris Lamb: Joining strings in POSIX shell

Thu, 10/09/2015 - 21:18

A common programming task is to glue (or "join") items together to create a single string. For example:

>>> ', '.join(['foo', 'bar', 'baz']) "foo, bar, baz"

Notice that we have three items but only two commas — this can be important if the tool we passing doesn't support trailing delimiters or we simply want the result to be human-readable.

Unfortunately, this can be inconvenient in POSIX shell where we construct strings via explicit concatenation. A naïve solution of:

RESULT="" for X in foo bar baz do RESULT="${RESULT}, ${X}" done

... incorrectly returns ", foo, bar, baz". We can solve this with a (cumbersome) counter or flag to only attach the delimiter when we need it:

COUNT=0 RESULT="" for X in foo bar baz do if [ "${COUNT}" = 0 ] then RESULT="${X}" else RESULT="${RESULT}, ${X}" fi COUNT=$((COUNT + 1)) done

One alternative is to use the little-known ":+" expansion modifier. Many people are familiar with ":-" for returning default values:

$ echo ${VAR:-fallback}

By contrast, the ":+" modifier inverts this logic, returning the fallback if the specified variable is actually set. This results in the elegant:

RESULT="" for X in foo bar baz do RESULT="${RESULT:+${RESULT}, }${X}" done
Categories: LUG Community Blogs

Daniel Silverstone (Kinnison): Orchestration, a cry for help

Tue, 08/09/2015 - 15:02

Over the past few years, a plethora of orchestration frameworks have been exploding onto the scene. Many have been around for quite a while but not all have the same sort of community behind them. For example there's a very interesting option in Joey Hess' Propellor but that is hurt by needing to be able to build Propellor on all the hosts you manage. On the other hand, Ansible is able to operate without installing extra software on your target hosts, but instead it ends up very latency-bound which can cause problems when your managed hosts are "far away".

I have considered CFEngine, Chef, Puppet and Salt in addition to the above mentioned options, but none of them feel quite right to me. I am looking for a way to manage a small number of hosts, at least one of which is not always online (my laptop) and all of which are essentially snowflakes whose sparkleybits I want some reasonable control over.

I have a few basic requirements which I worry would be hard to meet -- I want to be able to make changes to my hosts by editing a file and committing/pushing it to a git server. I want to be able to manage a host entirely over SSH from one or more systems, ideally without having to install the orchestration software on the target host, but where if the software is present it will get used to accelerate matters. I don't want to have to install Ruby or PHP on any system in order to have orchestration, and some of the systems I wish to manage simply can't compile Haskell stuff sanely. I'm not desperately interested in learning yet more DSLs, but I appreciate that it will be necessary, but I really don't want to have to learn more than one DSL simply to run one frameworks.

I don't want to have to learn strange and confusing combinations of file formats. For example, Ansible quite sensibly uses YAML for its structured data except for its host/group lists. It uses Jinja2 for its templating and looping, except for some things which it generates its own looping constructs inside its YAML. I also personally find Ansible's sportsball oriented terminology to be confusing, but that might just be me.

So what I'm hoping is that someone will be able to point me at a project which combines all the wonderful features of the above, with a need to learn only one DSL and which doesn't require to be installed on the managed host but which can benefit from being so installed, is driven from git, and won't hurt my already overly burdened brain.

Dear Lazyweb, pls. kthxbye.

Categories: LUG Community Blogs

Jonathan McDowell: Random post-DebConf 15 thoughts

Mon, 24/08/2015 - 15:18

There are a bunch of things I mean to blog about, but as I have just got fully home from Heidelberg and DebConf15 this afternoon that seems most appropriate to start with. It’s a bit of a set of disjoint thoughts, but I figure I should write them down while they’re in my head.

DebConf is an interesting conference. It’s the best opportunity the Debian project has every year to come together and actually spend a decent amount of time with each other. As a result it’s a fairly full on experience, with lots of planned talks as a basis and a wide range of technical discussions and general social interaction filling in whatever gaps are available. I always find it a thoroughly enjoyable experience, but equally I’m glad to be home and doing delightfully dull things like washing my clothes and buying fresh milk.

I have always been of the opinion that the key aspect of DebConf is the face time. It was thus great to see so many people there - we were told several times that this was the largest DebConf so far (~ 570 people IIRC). That’s good in the sense that it meant I got to speak to a lot of people (both old friends and new), but does mean that there are various people I know I didn’t spend enough, or in some cases any, time with. My apologies, but I think many of us were in the same situation. I don’t feel it made the conference any less productive for me - I managed to get a bunch of hacking done, discuss a number of open questions in person with various people and get pulled into various interesting discussions I hadn’t expected. In short, a typical DebConf.

Also I’d like to say that the venue worked out really well. I’ll admit I was dubious when I heard it was in a hostel, but it was well located (about a 30 minute walk into town, and a reasonable bus service available from just outside the door), self-contained with decent facilities (I’m a big believer in having DebConf talks + accommodation be as close as possible to each other) and the room was much better than expected (well, aside from the snoring but I can’t blame the DebConf organisers for that).

One of the surprising and interesting things for me that was different from previous DebConfs was the opportunity to have more conversations with a legal leaning. I expect to go to DebConf and do OpenPGP/general crypto related bits. I wasn’t expecting affirmation about the things I have learnt on my course over the past year, in terms of feeling that I could use that knowledge in the process of helping Debian. It provided me with some hope that I’ll be able to tie my technology and law skills together in a way that I will find suitably entertaining (as did various conversations where people expressed significant interest in the crossover).

Next year is in Cape Town, South Africa. It’s a long way (though I suppose no worse than Portland and I get to stay in the same time zone), and a quick look at flights indicates they’re quite expensive at the moment. The bid presentation did look pretty good though so as soon as the dates are confirmed (I believe this will happen as soon as there are signed contracts in place) I’ll take another look at flights.

In short, excellent DebConf, thanks to the organisers, lovely to see everyone I managed to speak to, apologies to those of you I didn’t manage to speak to. Hopefully see you in Cape Town next year.

Categories: LUG Community Blogs

Mick Morgan: update to domain privacy

Thu, 20/08/2015 - 18:55

At the end of last month I noted that I had been receiving multiple emails to each of the proxy addresses listed for my newly registered “private” domains. Intriguingly, whilst I was receiving at least three or four such emails a week before I wrote about it, I have had precisely zero since.

Probably coincidence, but a conspiracy theorist would have field day with that.

Categories: LUG Community Blogs

Mick Morgan: why privacy matters

Wed, 19/08/2015 - 17:53

Last month my wife and I shared a holiday with a couple of old friends. We have known this couple since before we got married, indeed, they attended our wedding. We consider them close friends and enjoy their company. One evening in a pub in Yorkshire, we got to discussing privacy, the Snowden revelations, and the implications of a global surveillance mechanism such as is used by both the UK and its Five Eyes partners (the US NSA in particular). To my complete surprise, Al expressed the view that he was fairly relaxed about the possibility that GCHQ should be capable of almost complete surveillance of his on-line activity since, in his view, “nothing I do can be of any interest to them, so why should I worry.”

I have met this view before, but oddly I had never heard Al express himself in quite this way in all the time I have known him. It bothers me that someone I love and trust, someone whose opinions I value, someone I consider to be intelligent and articulate and caring, should be so relaxed about so pernicious an activity as dragnet surveillance. It is not only the fact that Al himself is so relaxed that bothers me so much as the fact that if he does not care, then many, possibly most, people like him will not care either. That attitude plays into the hands of those, like Eric Schmidt, who purport to believe that “If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place.”

Back in October last year, Glenn Greenwald gave a TED talk on the topic, “Why privacy matters”. I recommended it to Al and I commend it to anyone who thinks, as he does, that dragnet surveillance doesn’t impact on them because they “are not doing anything wrong”.

Categories: LUG Community Blogs

Jonathan McDowell: Programming the FST-01 (gnuk) with a Bus Pirate + OpenOCD

Tue, 11/08/2015 - 14:29

Last year at DebConf14 Lucas authorized the purchase of a handful of gnuk devices, one of which I obtained. At the time it only supported 2048 bit RSA keys. I took a look at what might be involved in adding 4096 bit support during DebConf and managed to brick my device several times in doing so. Thankfully gniibe was on hand with his STLinkV2 to help me recover. However subsequently I was loathe to experiment further at home until I had a suitable programmer.

As it is this year has been busy and the 1.1.x release train is supposed to have 4K RSA (as well as ECC) support. DebConf15 is coming up and I felt I should finally sort out playing with the device properly. I still didn’t have a suitable programmer. Or did I? Could my trusty Bus Pirate help?

The FST-01 has an STM32F103TB on it. There is an exposed SWD port. I found a few projects that claimed to do SWD with a Bus Pirate - Will Donnelly has a much cloned Python project, the MC HCK project have a programmer in Ruby and there’s LibSWD though that’s targeted to smarter programmers. None of them worked for me; I could get the Python bits as far as correctly doing the ID of the device, but not reading the option bytes or successfully flashing (though I did manage an erase).

Enter the old favourite, OpenOCD. This already has SWD support and there’s an outstanding commit request to add Bus Pirate support. NodoNogard has a post on using the ST-Link/V2 with OpenOCD and the FST-01 which provided some useful pointers. I grabbed the patch from Gerrit, applied it to OpenOCD git and built an openocd.cfg that contained:

source [find interface/buspirate.cfg] buspirate_port /dev/ttyUSB0 buspirate_vreg 1 buspirate_mode normal transport select swd source [find target/stm32f1x.cfg]

My BP has the Seeed Studio probe cable, so my hookups look like this:

That’s BP MOSI (grey) to SWD IO, BP CLK (purple) to SWD CLK, BP 3.3V (red) to FST-01 PWR and BP GND (brown) to FST-01 GND. Once that was done I fired up OpenOCD in one terminal and did the following in another:

$ telnet localhost 4444 Trying ::1... Trying Connected to localhost. Escape character is '^]'. Open On-Chip Debugger > reset halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc Info : device id = 0x20036410 Info : SWD IDCODE 0x1ba01477 Error: Failed to read memory at 0x1ffff7e2 Warn : STM32 flash size failed, probe inaccurate - assuming 128k flash Info : flash size = 128kbytes > stm32f1x unlock 0 Device Security Bit Set stm32x unlocked. INFO: a reset or power cycle is required for the new settings to take effect. > reset halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc > flash write_image erase /home/noodles/checkouts/gnuk/src/build/gnuk.elf auto erase enabled wrote 109568 bytes from file /home/noodles/checkouts/gnuk/src/build/gnuk.elf in 95.055603s (1.126 KiB/s) > stm32f1x lock 0 stm32x locked > reset halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08000280 msp: 0x20005000

Then it was a matter of disconnecting the gnuk from the BP, plugging it into my USB port and seeing it come up successfully:

usb 1-2: new full-speed USB device number 11 using xhci_hcd usb 1-2: New USB device found, idVendor=234b, idProduct=0000 usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2: Product: Gnuk Token usb 1-2: Manufacturer: Free Software Initiative of Japan usb 1-2: SerialNumber: FSIJ-1.1.7-87063020 usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes

More once I actually have a 4K key loaded on it.

Categories: LUG Community Blogs