News aggregator

Mick Morgan: merry christmas 2015

Planet ALUG - Thu, 24/12/2015 - 16:17

It’s trivia’s birthday again (9 years old today!), so I just have to post to wish my readers (both of you, you know who you are….) a Merry Christmas and a happy New Year. Much has happened over the last year or so which has distracted me from blogging (life gets in the way sometimes) but I feel my muse returning so I may write more in the new year. Meanwhile, take a look at Alan Woodward’s update to Scott Culp’s 2000 essay “10 Immutable Laws Of Security” which he posted on the BBC site. It is called
have yourself a merry cyber-safe Christmas.

I’ll drink to that.

Categories: LUG Community Blogs

Steve Kemp: Finding and reporting trivial security issues

Planet HantsLUG - Tue, 22/12/2015 - 15:20

This week I'll be mostly doing drive-by bug-reporting.

As with last year we start by using the Debian Code Search, to look for obviously broken patterns such as "system.>./tmp/.*"

Once we find a fun match we examine the code and then report the bugs we find. Today that was stalin which runs some fantastic things on startup:

(system "uname -m >/tmp/QobiScheme.tmp") (system "rm -f /tmp/QobiScheme.tmp"))

We can exploit this like so:

$ ln -s /home/steve/HACK /tmp/QobiScheme.tmp $ ls -l /home/steve/HACK ls: cannot access /home/steve/HACK: No such file or directory

Now we run the script:

$ cd /tmp/stalin-0.11/benchmarks $ ./make-hello

And we see this:

$ ls -l /home/steve/HACK -rw-r--r-- 1 steve steve 6 Dec 22 08:30 /home/steve/HACK

For future reference the lsat looks horrifically bad - it writes multiple times to /tmp/lsat1.lsat and although it tries to detect races I'm not convinced. Something to look at in the future.

Categories: LUG Community Blogs

Chris Lamb: travis.debian.net

Planet ALUG - Sat, 19/12/2015 - 12:56

travis.debian.net is my new hosted utility to make it easier and cleaner to test your Debian packages on the Travis CI continuous integration platform, without duplicating configuration or scripts across mulitiple repositories.

You can read more about how it works, as well as follow the quick setup instructions.

As ever, patches welcome.

Categories: LUG Community Blogs

Testing Ubuntu Apps As A Service

Planet SurreyLUG - Wed, 16/12/2015 - 12:20

tl;dr. Stuart Langridge and I made an simple, easy to use, experimental app tester called Marvin, for Ubuntu Click Packages, which emails you screenshots and logs of your app while running on a real device you may not own.

I frequently get asked by new developers in the community to help test their apps on Ubuntu Phone. Typically they don’t want extensive testing of all features, just a simple “does it start and what does it look like on the device you have?”.

Often they don’t have a physical device when developing on the desktop with our SDK, but want an on-device sanity check before they upload to the store. Sometimes they have one device such as a phone, but want to see what their app looks like on a different one, perhaps a tablet.

I’ve been happy to help developers test their apps on various devices, but this doesn’t scale well, is time consuming and relies on me being online and having a phone which I’m happy to install random click packages on.

Meanwhile, at OggCamp I gave a short talk about our recent security incident on Ubuntu phone. During the Q&A and in the bar afterwards a couple of people suggested that we should have some system which enables automated testing of devices. They were coming at it from the security point of view, suggesting heavy instrumentation to find these kinds of issues before they hit the store.

While we (Canonical) already have tools which review apps before they go in the store, we currently don’t actually install and execute the apps on devices, and have no plan to implement such a service (that I know of).

I’m aware that other platforms have implemented automated systems for testing and instrumenting apps and wondered how hard it would be to setup something really basic to cover at least one of the two use cases above. So I took to Telegram to brainstorm with my good friend Stuart Langridge.

We thrashed out what was needed for a ‘minimum viable product’ and some nice-to-have future enhancements. Pretty soon after, with a bit of python and some hacked-together shell scripts, ‘Marvin‘ was born. I then approached Daniel McGuire who kindly provided some CSS to make it look prettier.

A developer can upload a click package to the site, and specify their email address & one or more of the available devices. Some time later they’ll get an email showing a few screenshots of the app or scope running on a device and pertinent logs extracted after it ran. While the developer waits, the website shows the current status as ‘pending’ (you’re in a queue), ‘claimed’ (by a device) and ‘finished’ (check your inbox).

This fulfills the simplest of use cases, making sure the app starts, and extracting the log if it didn’t. Clearly there’s plenty more it could potentially do, but this was our first target met.

Under the covers, there’s a device attached to a computer which checks periodically for uploaded clicks and processes them in sequence. In between each run the phone is cleaned up, so each test is done on a blank device. Currently it tests traditional apps/games and scopes, webapps are rejected, but may be supported later.

The reason we reject webapps is because currently the devices have no network access at all – no wifi or cellular data. So running webapps would just result in this:-

It’s experimental so not completely robust, being a prototype hacked together over a couple of weekends/evenings, but it works (for the most part). There’s no guarantees of availability of the service or indeed the devices. It could go offline at any time. Did I mention it’s experimental?

Significantly, I’ve disabled network access completely on the device, with no SIM inside, so any app which requires external network access is going to have a bad day. Locally installed apps however, will work fine.

We currently don’t do any interaction with the uploaded applications, but simply run them and wait a few seconds (to give it time to quiesce) then take a screenshot. The image at the top of this post shows what a typical email from Marvin looks like.

It contains:-

  • click-review.txt – The output from running the click review tools
    • Note: Apps which fail the click review process (the same one run by the click store) will not be installed or tested.
  • install.txt – Output from the commands used to install the click on the device – good for debugging install failures
  • Screenshot-0 – What the “home” app scope looks like with the click installed – useful for showing the icon and description
  • Screenshot-1 – What happens immediately after starting the app, showing the splash screen
  • Screenshot-2 – The app after 5 seconds
  • Screenshot-3 – The app after 10 seconds
    • Note: We attempt to de-duplicate the screenshots so you may not get all four if any are identical
  • application-log.txt – The actual output (stdout) from the application, pulled from ~/.cache/upstart
  • dmesg.txt – Any kernel logging generated from the app during the app run
  • device-version.txt – The output of ‘system-image-cli –info’ run on the device, so the developer knows what OTA level, channel and device it ran on

There’s clearly a ton of other things that could be added to the mail, or extra items which could be instrumented or monitored, and features we could add. Off the top of my head we could potentially add:-

  • Scripted touch/gestures
  • Networking
  • VPN endpoints (so the phone looks like it’s in a particular region)
  • Orientation changes
  • Faked GPS location
  • Video/screencast recording during runtime
  • Input from microphone / camera(s)
  • Specify which release / channel to flash on the device prior to testing

Clearly all of these need some careful thought and planning, especially those enabling network access from the device.

We’re interested in feedback from developers who might use Marvin, and suggestions for improvements we might make. There are a limited number of devices in the pool, and not all supported devices are currently available. In the future we may have more devices connected to Marvin as they become available.

So go and test your apps at marvin.popey.com!

Categories: LUG Community Blogs

Alan Pope: Testing Ubuntu Apps As A Service

Planet HantsLUG - Wed, 16/12/2015 - 12:20

tl;dr. Stuart Langridge and I made an simple, easy to use, experimental app tester called Marvin, for Ubuntu Click Packages, which emails you screenshots and logs of your app while running on a real device you may not own.

I frequently get asked by new developers in the community to help test their apps on Ubuntu Phone. Typically they don’t want extensive testing of all features, just a simple “does it start and what does it look like on the device you have?”.

Often they don’t have a physical device when developing on the desktop with our SDK, but want an on-device sanity check before they upload to the store. Sometimes they have one device such as a phone, but want to see what their app looks like on a different one, perhaps a tablet.

I’ve been happy to help developers test their apps on various devices, but this doesn’t scale well, is time consuming and relies on me being online and having a phone which I’m happy to install random click packages on.

Meanwhile, at OggCamp I gave a short talk about our recent security incident on Ubuntu phone. During the Q&A and in the bar afterwards a couple of people suggested that we should have some system which enables automated testing of devices. They were coming at it from the security point of view, suggesting heavy instrumentation to find these kinds of issues before they hit the store.

While we (Canonical) already have tools which review apps before they go in the store, we currently don’t actually install and execute the apps on devices, and have no plan to implement such a service (that I know of).

I’m aware that other platforms have implemented automated systems for testing and instrumenting apps and wondered how hard it would be to setup something really basic to cover at least one of the two use cases above. So I took to Telegram to brainstorm with my good friend Stuart Langridge.

We thrashed out what was needed for a ‘minimum viable product’ and some nice-to-have future enhancements. Pretty soon after, with a bit of python and some hacked-together shell scripts, ‘Marvin‘ was born. I then approached Daniel McGuire who kindly provided some CSS to make it look prettier.

A developer can upload a click package to the site, and specify their email address & one or more of the available devices. Some time later they’ll get an email showing a few screenshots of the app or scope running on a device and pertinent logs extracted after it ran. While the developer waits, the website shows the current status as ‘pending’ (you’re in a queue), ‘claimed’ (by a device) and ‘finished’ (check your inbox).

This fulfills the simplest of use cases, making sure the app starts, and extracting the log if it didn’t. Clearly there’s plenty more it could potentially do, but this was our first target met.

Under the covers, there’s a device attached to a computer which checks periodically for uploaded clicks and processes them in sequence. In between each run the phone is cleaned up, so each test is done on a blank device. Currently it tests traditional apps/games and scopes, webapps are rejected, but may be supported later.

The reason we reject webapps is because currently the devices have no network access at all – no wifi or cellular data. So running webapps would just result in this:-

It’s experimental so not completely robust, being a prototype hacked together over a couple of weekends/evenings, but it works (for the most part). There’s no guarantees of availability of the service or indeed the devices. It could go offline at any time. Did I mention it’s experimental?

Significantly, I’ve disabled network access completely on the device, with no SIM inside, so any app which requires external network access is going to have a bad day. Locally installed apps however, will work fine.

We currently don’t do any interaction with the uploaded applications, but simply run them and wait a few seconds (to give it time to quiesce) then take a screenshot. The image at the top of this post shows what a typical email from Marvin looks like.

It contains:-

  • click-review.txt – The output from running the click review tools
    • Note: Apps which fail the click review process (the same one run by the click store) will not be installed or tested.
  • install.txt – Output from the commands used to install the click on the device – good for debugging install failures
  • Screenshot-0 – What the “home” app scope looks like with the click installed – useful for showing the icon and description
  • Screenshot-1 – What happens immediately after starting the app, showing the splash screen
  • Screenshot-2 – The app after 5 seconds
  • Screenshot-3 – The app after 10 seconds
    • Note: We attempt to de-duplicate the screenshots so you may not get all four if any are identical
  • application-log.txt – The actual output (stdout) from the application, pulled from ~/.cache/upstart
  • dmesg.txt – Any kernel logging generated from the app during the app run
  • device-version.txt – The output of ‘system-image-cli –info’ run on the device, so the developer knows what OTA level, channel and device it ran on

There’s clearly a ton of other things that could be added to the mail, or extra items which could be instrumented or monitored, and features we could add. Off the top of my head we could potentially add:-

  • Scripted touch/gestures
  • Networking
  • VPN endpoints (so the phone looks like it’s in a particular region)
  • Orientation changes
  • Faked GPS location
  • Video/screencast recording during runtime
  • Input from microphone / camera(s)
  • Specify which release / channel to flash on the device prior to testing

Clearly all of these need some careful thought and planning, especially those enabling network access from the device.

We’re interested in feedback from developers who might use Marvin, and suggestions for improvements we might make. There are a limited number of devices in the pool, and not all supported devices are currently available. In the future we may have more devices connected to Marvin as they become available.

So go and test your apps at marvin.popey.com!

Categories: LUG Community Blogs

Why people really use #Instagram ?

Planet SurreyLUG - Wed, 16/12/2015 - 01:54

Why people really use #Instagram ?

The post Why people really use #Instagram ? appeared first on life at warp.

Categories: LUG Community Blogs

Chris Lamb: Peake Nationalism

Planet ALUG - Tue, 15/12/2015 - 23:59

Timothy Peake boarded the International Space Station a few hours ago becoming the United Kingdom's first official astronaut. It has become headline news, dominating the day's news cycle.

But whilst Peake left our pale blue dot with only the humble honorific "Mister", he has subsequently been awarded the dubious appellation of "British Astronaut".

Now, I'm no open-borders pan-nationalist and nor do I in any wish to detract or denigrate Peake's accomplishments — indeed, it is only out of a genuine respect of "our Tim's" achievements that I pen this in the first place — but are we still clinging to the idea that an extraordinary effort by a co-member of our species requires a nationalistic qualifier?

How much do we really have in common with our "fellow countrymen"? This is, after all, the International Space Station, to which Peake was elevated from Kazakhstan on the back of a Russian rocket, in order that he may peacefully collaborate with an American, a Ukrainian, etc.

I encountered the rebuttal that support of this nature is inspirational and incentive to others, but is it really motivating to know that — if you toil to achieve greatness in this life — then your accomplishments will be cheaply co-opted by mediocrities who only share the same colour passport as you? In this sense, isn't national pride really a form of national insecurity?

A "Briton" in space: if space travel can teach us anything, it's that broadcasting the specific patch of ground you were born in is an outdated, tribalistic contrivance and should be assigned to the dustbin of history.

Categories: LUG Community Blogs

Steve Engledow (stilvoid): Ford

Planet ALUG - Mon, 14/12/2015 - 22:23

Today I become a Firefox add-on developer!

Really, it was far too easy and a little disappointing that I needed to bother, as all I needed was a simple way to hide the browser chrome when I wanted a little more screen space for the content or I wanted a distraction-free environment for reading an article.

I wrote Focus Mode for Firefox to do just that :)

Now, someone tell me why that's not already a standard feature in Firefox. Or even better, tell me that it is and that I just failed to notice it. And while you're at it, tell me why I couldn't find an existing extension that does it!

Categories: LUG Community Blogs

Chris Lamb: try.diffoscope.org

Planet ALUG - Sun, 13/12/2015 - 12:05

If you haven't already come across it, diffoscope is a tool that reveals what makes files or directories actually different. It recursively unpacks archives of many kinds, transforming binary formats into more human-readable forms in order to make it easier to compare them. It can compare two tarballs, ISO images, PDF, squashfs images, etc.

Anyway, yesterday I hacked together try.diffoscope.org which lets anyone easily try out and share these in-depth comparisons using just a web browser.

The underlying idea is not only to provide a useful service, but also that it will publicise and spread the usage of diffoscope, resulting in net improvements that will feed back into the Reproducible Builds effort.

As usual, patches welcome.

Categories: LUG Community Blogs

Andy Smith: Disabling the default IPMI credentials on a Supermicro server

Planet HantsLUG - Sat, 12/12/2015 - 00:34

In an earlier post I mentioned that you should disable the default ADMIN / ADMIN credentials on the IPMI controller. Here’s how.

Install ipmitool

ipmitool is the utility that you will use from the command line of another machine in order to interact with the IPMI controllers on your servers.

# apt-get install ipmitool List the current users $ ipmitool -I lanplus -H 192.168.1.22 -U ADMIN -a user list Password: ID Name Callin Link Auth IPMI Msg Channel Priv Limit 2 ADMIN false false true ADMINISTRATOR

Here you are specifying the IP address of the server’s IPMI controller. ADMIN is the IPMI user name you will use to log in, and it’s prompting you for the password which is also ADMIN by default.

Add a new user

You should add a new user with a name other than ADMIN.

I suppose it would be safe to just change the password of the existing ADMIN user, but there is no need to have it named that, so you may as well pick a new name.

$ ipmitool -I lanplus -H 192.168.1.22 -U ADMIN -a user set name 3 somename Password: $ ipmitool -I lanplus -H 192.168.1.22 -U ADMIN -a user set password 3 Password: Password for user 3: Password for user 3: $ ipmitool -I lanplus -H 192.168.1.22 -U ADMIN -a channel setaccess 1 3 link=on ipmi=on callin=on privilege=4 Password: $ ipmitool -I lanplus -H 192.168.1.22 -U ADMIN -a user enable 3 Password:

From this point on you can switch to using the new user instead.

$ ipmitool -I lanplus -H 192.168.1.22 -U somename -a user list Password: ID Name Callin Link Auth IPMI Msg Channel Priv Limit 2 ADMIN false false true ADMINISTRATOR 3 somename true true true ADMINISTRATOR Disable ADMIN user

Before doing this bit you may wish to check that the new user you added works for everything you need it to. Those things might include:

  • ssh to somename@192.168.1.22
  • Log in on web interface at https://192.168.1.22/
  • Various ipmitool commands like querying power status: $ ipmitool -I lanplus -H 192.168.1.22 -U somename -a power status Password: Chassis power is on

If all of that is okay then you can disable ADMIN:

$ ipmitool -I lanplus -H 192.168.1.22 -U somename -a user disable 2 Password:

If you are paranoid (or this is just the first time you’ve done this) you could now check to see that none of the above things now work when you try to use ADMIN / ADMIN.

Specifying the password

I have not done so in these examples but if you get bored of typing the password every time then you could put it in the IPMI_PASSWORD environment variable and use -E instead of -a on the ipmitool command line.

When setting the IPMI_PASSWORD environment variable you probably don’t want it logged in your shell’s history file. Depending on which shell you use there may be different ways to achieve that.

With bash, if you have ignorespace in the HISTCONTROL environment variable then commands prefixed by one or more spaces won’t be logged. Alternatively you could temporarily disable history logging with:

$ set +o history $ sensitive commend goes here $ set -o history # re-enable history logging

So anyway…

$ echo $HISTCONTROL ignoredups:ignorespace $ export IPMI_PASSWORD=letmein $ # ^ note the leading spaces here $ # to prevent the shell logging it $ ipmitool -I lanplus -H 192.168.1.22 -U somename -E power status Chassis Power is on
Categories: LUG Community Blogs

Andy Smith: Installing Debian by PXE using Supermicro IPMI Serial over LAN

Planet HantsLUG - Fri, 11/12/2015 - 18:50

Here’s how to install Debian jessie on a Supermicro server using PXE boot and the IPMI serial-over-LAN.

Using these instructions you will be able to complete an install of a remote machine, although you will initially need access to the BIOS to configure the IPMI part.

BIOS settings

This bit needs you to be in the same location as the machine, or else have someone who is make the required changes.

Press DEL to go into the BIOS configuration.

Under Advanced > PCIe/PCI/PnP Configuration make sure that the network interface through which you’ll reach your PXE server has the “PXE” option ROM set:

Under Advanced > Serial Port Console Redirection you’ll want to enable SOL Console Redirection.

(Pictured here is also COM1 Console Redirection. This is for the physical serial port on the machine, not the one in the IPMI.)

Under SOL Console Redirection Settings you may as well set the Bits per second to 115200.

Now it’s time to configure the IPMI so you can interact with it over the network. Under IPMI > BMC Network Configuration, put the IPMI on your management network:

Connecting to the IPMI serial

With the above BIOS settings in place you should be able to save and reboot and then connect to the IPMI serial console. The default credentials are ADMIn / ADMIN which you should of course change with ipmitool, but that is for a different post.

There’s two ways to connect to the serial-over-LAN: You can ssh to the IPMI controller, or you can use ipmitool. Personally I prefer ssh, but the ipmitool way is like this:

$ ipmitool -I lanplus -H 192.168.1.22 -U ADMIN -a sol activate

The ssh way:

$ ssh ADMIN@192.168.1.22 The authenticity of host '192.168.1.22 (192.168.1.22)' can't be established. RSA key fingerprint is b7:e1:12:94:37:81:fc:f7:db:6f:1c:00:e4:e0:e1:c4. Are you sure you want to continue connecting (yes/no)? Warning: Permanently added '192.168.1.22,192.168.1.22' (RSA) to the list of known hosts. ADMIN@192.168.1.22's password:   ATEN SMASH-CLP System Management Shell, version 1.05 Copyright (c) 2008-2009 by ATEN International CO., Ltd. All Rights Reserved     -> cd /system1/sol1 /system1/sol1   -> start /system1/sol1 press <Enter>, <Esc>, and then <T> to terminate session (press the keys in sequence, one after the other)

They both end up displaying basically the same thing.

The serial console should just be displaying the boot process, which won’t go anywhere.

DHCP and TFTP server

You will need to configure a DHCP and TFTP server on an already-existing machine on the same LAN as your new server. They can both run on the same host.

The DHCP server responds to the initial requests for IP address configuration and passes along where to get the boot environment from. The TFTP server serves up that boot environment. The boot environment here consists of a kernel, initramfs and some configuration for passing arguments to the bootloader/kernel. The boot environment is provided by the Debian project.

DHCP

I’m using isc-dhcp-server. Its configuration file is at /etc/dhcp/dhcpd.conf.

You’ll need to know the MAC address of the server, which can be obtained either from the front page of the IPMI controller’s web interface (i.e. https://192.168.1.22/ in this case) or else it is displayed on the serial console when it attempts to do a PXE boot. So, add a section for that:

subnet 192.168.2.0 netmask 255.255.255.0 { }   host foo { hardware ethernet 0C:C4:7A:7C:28:40; fixed-address 192.168.2.22; filename "pxelinux.0"; next-server 192.168.2.251; option subnet-mask 255.255.255.0; option routers 192.168.2.1; }

Here we set the network configuration of the new server with fixed-address, option subnet-mask and option routers. The IP address in next-server refers to the IP address of the TFTP server, and pxelinux.0 is what the new server will download from it.

Make sure that is running:

# service isc-dhcp-server start

DHCP uses UDP port 67, so make sure that is allowed through your firewall.

TFTP

A number of different TFTP servers are available. I use tftpd-hpa, which is mostly configured by variables in /etc/default/tftp-hpa:

TFTP_OPTIONS="--secure" TFTP_USERNAME="tftp" TFTP_DIRECTORY="/srv/tftp" TFTP_ADDRESS="0.0.0.0:69"

TFTP_DIRECTORY is where you’ll put the files for the PXE environment.

Make sure that the TFTP server is running:

# service tftpd-hpa start

TFTP uses UDP port 69, so make sure that is allowed through your firewall.

Download the netboot files from your local Debian mirror:

$ cd /srv/tftp $ curl -s http://ftp.YOUR-MIRROR.debian.org/debian/dists/jessie/main/installer-amd64/current/images/netboot/netboot.tar.gz | sudo tar zxvf - ./ ./version.info ./ldlinux.c32 ./pxelinux.0 ./pxelinux.cfg ./debian-installer/ ./debian-installer/amd64/ ./debian-installer/amd64/bootnetx64.efi ./debian-installer/amd64/grub/ ./debian-installer/amd64/grub/grub.cfg ./debian-installer/amd64/grub/font.pf2 …

(This assumes you are installing a device with architecture amd64.)

At this point your TFTP server root should contain a debian-installer subdirectory and a couple of links into it:

$ ls -l . total 8 drwxrwxr-x 3 root root 4096 Jun 4 2015 debian-installer lrwxrwxrwx 1 root root 47 Jun 4 2015 ldlinux.c32 -> debian-installer/amd64/boot-screens/ldlinux.c32 lrwxrwxrwx 1 root root 33 Jun 4 2015 pxelinux.0 -> debian-installer/amd64/pxelinux.0 lrwxrwxrwx 1 root root 35 Jun 4 2015 pxelinux.cfg -> debian-installer/amd64/pxelinux.cfg -rw-rw-r-- 1 root root 61 Jun 4 2015 version.info

You could now boot your server and it would call out to PXE to do its netboot, but would be displaying the installer process on the VGA output. If you intend to carry it out using the Remote Console facility of the IPMI interface then that may be good enough. If you want to do it over the serial-over-LAN though, you’ll need to edit some of the files that came out of the netboot.tar.gz to configure that.

Here’s a list of the files you need to edit. All you are doing in each one is telling it to use serial console. The changes are quite mechanical so you can easily come up with a script to do it, but here I will show the changes verbosely. All the files live in the debian-installer/amd64/boot-screens/ directory.

ttyS1 is used here because this system has a real serial port on ttyS0. 115200 is the baud rate of ttyS1 as configured in the BIOS earlier.

adtxt.cfg

From:

label expert menu label ^Expert install kernel debian-installer/amd64/linux append priority=low vga=788 initrd=debian-installer/amd64/initrd.gz --- include debian-installer/amd64/boot-screens/rqtxt.cfg label auto menu label ^Automated install kernel debian-installer/amd64/linux append auto=true priority=critical vga=788 initrd=debian-installer/amd64/initrd.gz --- quiet

To:

label expert menu label ^Expert install kernel debian-installer/amd64/linux append priority=low console=ttyS1,115200n8 initrd=debian-installer/amd64/initrd.gz --- include debian-installer/amd64/boot-screens/rqtxt.cfg label auto menu label ^Automated install kernel debian-installer/amd64/linux append auto=true priority=critical console=ttyS1,115200n8 initrd=debian-installer/amd64/initrd.gz --- quiet rqtxt.cfg

From:

label rescue menu label ^Rescue mode kernel debian-installer/amd64/linux append vga=788 initrd=debian-installer/amd64/initrd.gz rescue/enable=true --- quiet

To:

label rescue menu label ^Rescue mode kernel debian-installer/amd64/linux append console=ttyS1,115200n8 initrd=debian-installer/amd64/initrd.gz rescue/enable=true --- quiet syslinux.cfg

From:

# D-I config version 2.0 # search path for the c32 support libraries (libcom32, libutil etc.) path debian-installer/amd64/boot-screens/ include debian-installer/amd64/boot-screens/menu.cfg default debian-installer/amd64/boot-screens/vesamenu.c32 prompt 0 timeout 0

To:

serial 1 115200 console 1 # D-I config version 2.0 # search path for the c32 support libraries (libcom32, libutil etc.) path debian-installer/amd64/boot-screens/ include debian-installer/amd64/boot-screens/menu.cfg default debian-installer/amd64/boot-screens/vesamenu.c32 prompt 0 timeout 0 txt.cfg

From:

default install label install menu label ^Install menu default kernel debian-installer/amd64/linux append vga=788 initrd=debian-installer/amd64/initrd.gz --- quiet

To:

default install label install menu label ^Install menu default kernel debian-installer/amd64/linux append console=ttyS1,115200n8 initrd=debian-installer/amd64/initrd.gz --- quiet Perform the install

Connect to the serial-over-LAN and get started. If the server doesn’t have anything currently installed then it should go straight to trying PXE boot. If it does have something on the storage that it would boot then you will have to use F12 at the BIOS screen to convince it to jump straight to PXE boot.

$ ssh ADMIN@192.168.1.22 ADMIN@192.168.1.22's password:   ATEN SMASH-CLP System Management Shell, version 1.05 Copyright (c) 2008-2009 by ATEN International CO., Ltd. All Rights Reserved     -> cd /system1/sol1 /system1/sol1   -> start /system1/sol1 press <Enter>, <Esc>, and then <T> to terminate session (press the keys in sequence, one after the other)   Intel(R) Boot Agent GE v1.5.13 Copyright (C) 1997-2013, Intel Corporation   CLIENT MAC ADDR: 0C C4 7A 7C 28 40 GUID: 00000000 0000 0000 0000 0CC47A7C2840 CLIENT IP: 192.168.2.22 MASK: 255.255.255.0 DHCP IP: 192.168.2.252 GATEWAY IP: 192.168.2.1   PXELINUX 6.03 PXE 20150107 Copyright (C) 1994-2014 H. Peter Anvin et al             ┌───────────────────────────────────────┐ │ Debian GNU/Linux installer boot menu │ ├───────────────────────────────────────┤ │ Install │ │ Advanced options > │ │ Help │ │ Install with speech synthesis │ │ │ │ │ │ │ │ │ │ │ │ │ └───────────────────────────────────────┘       Press ENTER to boot or TAB to edit a menu entry     ┌───────────────────────┤ [!!] Select a language ├────────────────────────┐ │ │ │ Choose the language to be used for the installation process. The │ │ selected language will also be the default language for the installed │ │ system. │ │ │ │ Language: │ │ │ │ C │ │ English │ │ │ │ <Go Back> │ │ │ └─────────────────────────────────────────────────────────────────────────┘         <Tab> moves; <Space> selects; <Enter> activates buttons

…and now the installation proceeds as normal.

At the end of this you should be left with a system that uses ttyS1 for its console. You may need to tweak that depending on whether you want the VGA console also.

Categories: LUG Community Blogs

Andy Smith: Audience tickets for Stewart Lee’s Comedy Vehicle

Planet HantsLUG - Thu, 10/12/2015 - 06:59

Last night Jenny and I got the chance to be in the audience for a recording of what will become (some percentage of) four episodes of Stewart Lee’s Comedy Vehicle season 4. Once we actually got in it was a really enjoyable experience, although as usual SRO Audiences were somewhat chaotic with their ticketing procedures.

I’d heard about the chance to get priority audience tickets from the Stewart Lee mailing list, so I applied, but the tickets I got were just their standard ones. From past experience I knew this would mean having to get there really early and queue for ages and still not be sure of getting in, so for most shows on the SRO Audiences site I don’t normally bother. As I particularly like Stewart Lee I decided to persevere this time.

The instructions said they’d be greeting us from 6.20pm, so I decided getting there about an hour early would be a good idea. I know from past experience that they massively over-subscribe their tickets in order to never ever have empty seats. That makes it very difficult to guess how early to be, and I hadn’t been to a Comedy Vehicle recording before either.

The venue was The Mildmay Club in Stoke Newington which was also the venue for all previous recordings of Comedy Vehicle. A bit of a trek from Feltham – train to Richmond then most of the way along the Overground towards Stratford; a good 90 minutes door to door. Nearest station Canonbury but we decided to go early and get some food at Nando’s Dalston first.

We got to the Mildmay Club about 5.25pm and there were already about 15 people queuing outside. Pretty soon the doorman let us in, but only as far as a table just inside the doors where a guy gave us numbered wristbands and told us to come back at 7pm.

This was a bit confusing as we weren’t sure whether that meant we were definitely getting in or if we’d still have to queue (and thus should actually come back before 7). So I asked,

“does the wristband mean we’re definitely getting in?”

“We’ll do our best to get as many people in as we can. We won’t know until 7pm,”

was the non-answer. People piling up behind us and they wanted us out of the way, so off we went.

Having already eaten we didn’t really have anything else to do, so we had a bit of an aimless wander around Newington Green for half an hour or so before arriving back outside the club again, where the queue was now a crowd bustling around the entrance and trailing off in both directions along the street. We decided to get back in the queue going to the right of the club, which was slowly shrinking, with the idea of asking if we were in the right place once we got to the front. All of the people in this queue were yet to collect their wristbands.

Having got to the front of this queue it was confirmed that we should wait around outside until 7pm, though still no idea whether we would get in or by what process this would be decided. We shuffled into the other queue to the left of the club which consisted of people like us who already had wristbands.

While in this queue, we heard calls for various colours of wristband that weren’t ours (white), and eventually all people in front of us had been called into the club. By about quarter past 6 we’d watched quite a large number of people with colourful wristbands get into the building, and we were starting to seriously consider that we might not be getting into this thing, despite the fact that we were amongst the first 15 people to arrive.

At this point a different member of staff came out and told us off for queuing to the left of the club, because

“you’re not allowed to queue past the shops”

and told us to queue to the right with all the other people who still hadn’t got wristbands yet. Various grumblings on the subject of the queue being really long and how will we know what is going on were heard, to which the response was,

“it doesn’t matter where you are, your wristbands are numbered and we’ll call people in number order anyway. You can go away and come back at 7pm if you like. Nothing is happening before 7pm.”

Well, we didn’t have anything else to do for the next 45 minutes anyway, and there was lack of trust that everyone involved was giving us the same/correct information, so we decided to remain in this mostly-linear-collection-of-people-which-was-not-a-queue-because-it-would-be-called-in-number-order.

About 6.55pm a staff member popped their head out the door and shouted,

“we’re delayed by about ten minutes but we do love you and we’ll start getting you inside soon.”

And then just a minute or two later he’s back and shouting out,

“wristband numbers below 510, come this way!”

We were 506 and 507.

The exterior of the Mildmay Club isn’t in the best condition. It looks pretty shabby. Inside though it’s quite nice. We were ushered into the bar area which is pretty much the same as the bar of every working men’s club or British Legion club that you have ever seen.

Even though we were amongst the first few white wristband people in, the room was really full already. These must have been all the priority ticket people we saw going in ahead of us. Nowhere for us to sit except the edge of a low stage directly in front of a speaker pumping out blues and Hendrix. Again we started to worry that we would not be getting in to the recording.

It must have been about 7.20pm when they started calling the colourful wristband people out of the bar and in to the theatre. The room slowly drained until it seemed like there were only about ten of us left. And then,

“white wristbands numbered 508 and below please!”

We rushed into the theatre to be confronted with mostly full seating.

“You want to be sat together don’t you?”

“Yes!”

“Oh, just take those reserved seats, they’ve blown it now, they’re too late.”

Score! I prodded Jenny in the direction of a set of four previously reserved seats that were in a great position. We were amongst the last twenty or so people to get in. I think if we had shown up even ten minutes later to get the wristbands then we wouldn’t have made it.

In contrast to the outside of the building the theatre itself was really quite nice, very interesting decor, and surprisingly large compared to the impression you get from seeing it on television.

Stewart did two sets of 28 minute pieces, then a short interval and then another 2×28 minutes, so almost two hours. I believe there were recordings on three nights so that’s potentially 12 episodes worth of material, but given that

  1. All the previous series had 6 episodes.
  2. Stewart made a comment at one point about moving something on stage for continuity with the previous night’s recording.

then I assume there’s two recordings of each episode’s material from which they’ll edit together the best bits.

The material itself was great, so fans of Comedy Vehicle have definitely got something to look forward to. If you have previously attempted to consume Stewart Lee’s comedy and found the experience unpalatable then I don’t think anything is going to change for you – in fact it might upset you even more, to be honest. Other than that I’m not going to say anything about it as that would spoil it and I couldn’t do it justice anyway.

Oh, apart from that it’s really endearing to see Stew make himself laugh in the middle of one of his own rants and have to take a moment to compose himself.

As for SRO Audiences, I possibly shouldn’t moan as I have no actual experience of trying to cram hundreds of people into a free event and their first concern has got to be having the audience side of things run smoothly for the production, not for the audience. I get that. All I would say is that:

  • Being very clear with people at wristband issuing time that they will be called in by number, and giving a realistic time for when the numbers would be called, would be helpful. This wasn’t clear for us so on the one hand we hung around being in the way a bit, but on the other hand I’m glad that we didn’t leave it until 7pm to come back because our numbers were called before 7pm and we did only just get in.
  • Doing your best to turn people away early when they have no realistic chance of getting in would be good. There were loads of people with higher number wristbands than us that we did not see in the theatre later. Unsure if they got eventually sent home or if they ended up watching the recording on TV in the bar. At previous SRO Audiences recordings I’ve waited right up until show start time to be told to go home though.
Categories: LUG Community Blogs

Mick Morgan: knees and other jerks

Planet ALUG - Tue, 08/12/2015 - 16:20

On sunday, the motherboard intially reported that, in the wake of the Paris atrocities of November 13th, the French Government was proposing to ban Tor and free WiFi. As it turns out, this is not strictly accurate. The report was later corrected – thus:

Correction: The initial headline and copy of this article suggested that the proposals to block Tor and control free wifi were already part of a proposed law. These are in fact points that the French police and gendarmes would like to see included in the bill, according to the document seen by Le Monde. The headline and copy have been updated to clarify this; we apologise for the error.

Nevertheless, the actual story is still worrying. Governments of all shades seem to react badly when they feel that they must be seen to “do something”. We, in the UK, have already seen how the desire to “do something” results in unfortunate over reaction and ill-thought proposals for legislation. So it is sad to see the French (for whom I have much admiration) apparently reacting to Paris by opting to clamp down on civil liberties. I’d like to think that the reality is not as bad as the initial report suggested though. Certainly the motherboard post now makes clear that:

French law enforcement wants to have (my emphasis) several powers added to a proposed law, including the move to forbid and block the use of the Tor anonymity network, according to an internal document from the Ministry of Interior seen by French newspaper Le Monde.

It continues:

French law enforcement wish to “Forbid free and shared wi-fi connections” during a state of emergency. This comes from a police opinion included in the document: the reason being that it is apparently difficult to track individuals who use public wi-fi networks.

Noting that China actively blocks connections to Tor, the article continues:

If the French really wanted to block Tor, they might have to consider a model similar to the Chinese regime’s. Naturally, that might be worrying for anyone that cares about free-speech, increasing surveillance, or, say, democracy.

Let’s just hope that sense prevails and Western democracies do not react to terrorism in a way which reduces the very freedoms we cherish so much.

Categories: LUG Community Blogs

Steve Kemp: I jumped on the SSL-bandwagon

Planet HantsLUG - Fri, 04/12/2015 - 18:03

Like everybody else on the internet today was the day I started rolling out SSL certificates, via let's encrypt.

The process wasn't too difficult, but I did have to make some changes. Pretty much every website I have runs under its own UID, and I use a proxy to pass content through to the right back-end.

Running 15+ webservers feels like overkill, but it means that the code running start.steve.org.uk cannot read/modify/break the code that is running this blog - because they run as different UIDs.

To start with I made sure that all requests to the top-level /.well-known directory were shunted to a local directory - via this in /etc/apache2/conf-enabled/well-known.conf:

Alias /.well-known/ /srv/well-known/ <Directory "/srv/well-known/"> ForceType text/plain Options Indexes FollowSymLinks MultiViews AllowOverride all AuthType None Require all granted </Directory>

Then configured each proxy to avoid forwarding that path to the back-ends, by adding this to each of the individual virtual-hosts that run proxying:

<Proxy *> Order allow,deny Allow from all </Proxy> ProxyPass /.well-known ! ProxyPass / http://localhost:$port/ ..

Then it came to be time to actually generate the certificates. Rather than using the official client I used a simpler one that allowed me to generate requests easily:

CSR=/etc/apache2/ssl/csr/ KEYS=/etc/apache2/ssl/keys/ CERTS=/etc/apache2/ssl/certs/ # generate a key openssl genrsa 4096 > $KEYS/lumail.key # make a CSR openssl req -new -sha256 -key $KEYS/lumail.key -subj "/" -reqexts SAN \ -config <(cat /etc/ssl/openssl.cnf \ <(printf "[SAN]\nsubjectAltName=DNS:www.lumail.org,DNS:lumail.org")) \ > $CSR/lumail.csr # Do the validation acme_tiny.py --account-key ./account.key --csr $CSR/lumail.csr \ --acme-dir /srv/well-known/acme-challenge/ > $CERTS/lumail.crt.new

And then I was done. Along the way I found some niggles:

  • If you have a host that listens on IPv6 only you cannot validate your request - this seems like a clear failure.
  • It is assumed that you generate all your certificates in their live-location. e.g. You cannot generate a certificate for foo.example.com on the host bar.example.com.
  • If you forward HTTP -> HTTPS the validation fails. I had to setup rewrite rules to avoid this, for example lumail.org contains this:
    • RewriteEngine On
    • RewriteCond %{REQUEST_URI} !^/.well-known
    • RewriteRule ^/(.*) https://lumail.org/$1 [L]

The first issue is an annoyance. The second issue is a real pain. For example *.steve.org.uk listens on one machine except for webmail.steve.org.uk. Since there are no wildcards created a single certificate with Alt-names for a bunch of names such as:

  • ..
  • blog.steve.org.uk
  • start.steve.org.uk
  • ..

Then seperately create a certificate for the webmail host - which I've honestly not done yet.

Still I wrote a nice little script to generate SSL for a number of domains, with different Alt-Names, wrapping around the acme_tiny.py script, and regenerating all my deployed certificates is now a two minute job.

(People talk about renewing certificates. I don't see the gain. Just replace them utterly every two months and you'll be fine.)

Categories: LUG Community Blogs

#GNU books @FSF ordered. Satisfaction in this.

Planet SurreyLUG - Fri, 04/12/2015 - 09:51

I have an eReader, but I prefer physical books :)

#GNU books ordered.  Satisfaction in this.

The post #GNU books @FSF ordered. Satisfaction in this. appeared first on life at warp.

Categories: LUG Community Blogs

Debian Bits: Software Freedom Conservancy needs your support!

Planet HantsLUG - Thu, 03/12/2015 - 23:30

"Software Freedom Conservancy helps promote, improve, develop, and defend Free, Libre, and Open Source Software (FLOSS) projects. Conservancy provides a non-profit home and infrastructure for FLOSS projects.", that is how Software Freedom Conservancy defines itself. Organizations like Conservancy allow free software developers to focus on what they do the best by doing copyleft enforcement, taking care of legal aspects and provide many services to its project members.

Last August, Debian and Conservancy announced a partnership and formed the Copyright Aggregation Project where, among other things, Conservancy will be able to hold copyrights for some Debian works and ensure compliance with copyleft so that those works remain in free software.

Recently, Conservancy launched a major fundraising campaign and needs more individual supporters to gain more sustainable and independent funding. This will allow the Conservancy to continue its efforts towards convincing more companies to comply with free software licenses such as the GPL and take legal actions when dialogue turns out to be unsuccessful. Conservancy needs your support now, more than ever!

Many Debian Developers and Contributors have already become Conservancy supporters. Please consider signing up as a supporter on https://sfconservancy.org/supporter/!

Categories: LUG Community Blogs

Discovering Dokuwiki

Planet SurreyLUG - Thu, 03/12/2015 - 10:15

I was looking for a Wiki for managing the sharing of a boat, including booking usage, task lists and maintenance, as well as acting as a repository for any-and-all information available.

What it looked like was incidental, but it needed to be really simple for users to edit pages quickly. I wanted to squeeze it onto a work server, so it also needed to be really lightweight.

The Choices

I have experience of using both Wordpress and Drupal, but felt they were too complex and cumbersome for this use-case. I have also used MediaWiki in the past but, whilst easy to edit, I found it fairly cumbersome to use - it is after all designed for managing vast sites.

In the end I opted for DokuWiki, after stumbling across a site that recommended it as a really simple alternative to MediaWiki.

Installing DokuWiki

Dokuwiki is really easy to install, with delightfully simple instructions for Apache, but following my lightweight wishes I decided to try Nginx for the first time. Unfortunately I could not immediately find Nginx Instructions from DokuWiki, so instead followed these Nginx Instructions from Rose Hosting.

On first attempt the landing page would not load, but the nginx logs were very clear and helpful in pointing me to increasing a value of server_names_hash_bucket_size in /etc/nginx/nginx.conf. This I found was commented out (with a default of 32), so I uncommented it and increased it to 64 and restarted nginx. At last I could reach the install page and from that point it all worked perfectly.

Later I decided to implement Nginx Pretty URLs, which again worked perfectly.

First Impressions

The main thing I love about DokuWiki is the simplicity.

Creating users is trivial, creating and editing pages is a doddle, there is a reasonably sane way of managing media files, and the Wiki syntax is bearable (not Markdown sadly).

Despite this simplicity, each time I have come across something I'd like to tweak, then there has been a way to do it without resorting to nasty hacks. Where Plugins are required, these can be installed in seconds via the web interface.

Most of what I was trying to do with this boat site was simply a matter of creating pages, but I did come across a few exceptions:

Checklists

One of the key uses for the site is to host a number of checklists, but I wanted tickboxes against each item. Not essential clearly, but it turned out to be trivial, simply deciding how to type a tickbox, e.g. square brackets for incomplete [] and [x] for complete, and then adding DokuWiki Entities to convert these into the appropriate character.

Bookings

The main problem that I faced was how to enable boat users to book time on the boat and in the end I settled on using simple text tables, but to make them simpler to edit I added Andreas Gohr's excellent Edittable Plugin. This plug-in is so good that I would always install it in any DokuWiki that will have tables.

Whilst this will certainly do for now, I am on the look out for some sort of site to manage bookings properly - if you know of anything suitable please do comment below, otherwise at some point I will probably write one in Perl Dancer!

Conclusions

Under the Use Cases on the DokuWiki website there is the suggestion of using it for a Private Notebook - having used DokuWiki I can totally see how that would make sense - it is that simple to create and edit.

DokuWiki has definitely filled a gap in my web toolbox, alongside Perl Dancer and Jekyll.

Categories: LUG Community Blogs

Great. Off we go to bomb an already ruined country. #SaveSyria

Planet SurreyLUG - Wed, 02/12/2015 - 23:30

Great. Off we go to bomb an already ruined country. #SaveSyria

The post Great. Off we go to bomb an already ruined country. #SaveSyria appeared first on life at warp.

Categories: LUG Community Blogs

Work this week has gone nova. Exploding, then collapsing in a big heap!

Planet SurreyLUG - Wed, 02/12/2015 - 22:55

Work this week has gone nova. Exploding, then collapsing in a big heap!

The post Work this week has gone nova. Exploding, then collapsing in a big heap! appeared first on life at warp.

Categories: LUG Community Blogs
Syndicate content