LUG Community Blogs

Meeting at "The Moon Under Water"

Wolverhampton LUG News - Mon, 04/08/2014 - 07:33
Event-Date: Wednesday, 6 August, 2014 - 19:30 to 23:00Body: 53-55 Lichfield St Wolverhampton West Midlands WV1 1EQ Eat, Drink and talk Linux
Categories: LUG Community Blogs

Debian Bits: DebConf14 - schedule available

Planet HantsLUG - Sun, 03/08/2014 - 22:25

Debconf14 will be held in three weeks in Portland, OR, USA and we're happy to announce that the schedule is already available. Of course, it is still possible for some minor changes to happen!

DebConf will open on Saturday, August 23 with the Welcome talk followed by two highlighted talks:

  • Debian in the Dark Ages of Free Software by Stefano Zacchiroli, former Debian Project Leader. Stefano will speak about the achievements realized by Free Software communities in the past years, and how now, despite the visible success, this freedom is being threatened by the current technology trends, and how can Debian help to preserve the so well deserved freedom.

  • Weapons of the Geek by Biella Coleman, cultural anthropologist, who researches, writes, and teaches on computer hackers and digital activism will share with us part of her research, explaining how online communities can have a big impact on world politics today.

There will also be also a plethora of social events, such as our traditional cheese and wine party, our group photo and our day trip.

The complete schedule can be found at: https://summit.debconf.org/debconf14/

DebConf talks will be broadcast live on the Internet when possible, and videos of the talks will be published on the web along with the presentation slides.

Categories: LUG Community Blogs

Bring-A-Box 9th August 2014, Red Hat

Surrey LUG - Sat, 02/08/2014 - 14:14
Start: 2014-08-09 11:00 End: 2014-08-09 11:00

We have regular sessions each month. Bring a 'box', bring a notebook, bring anything that might run Linux, or just bring yourself and enjoy socialising/learning/teaching or simply chilling out!

Back to the excellent Red Hat offices in Farnborough, Hampshire on Saturday 9th August - thanks to Dominic Cleal for hosting us..

Categories: LUG Community Blogs

Martin Wimpress: ZNC IRC proxy

Planet HantsLUG - Sat, 02/08/2014 - 10:10

I have been using the BIP IRC proxy that maintains a persistent connection(s) to a list of IRC channels. However, I've heard good things about ZNC and decided to give it a try.

The purpose of an IRC proxy, or bouncer, is that you can then point your IRC clients to them to maintain a transparent connection from multiple clients and playback the conversations that took place while you were away.

Installing ZNC

The ZNC package for Debian Wheezy are very old, so I decide to install from source.

Install required packages

We first need to make sure we have all the packages required to build ZNC.

sudo apt-get install build-essential libssl-dev libperl-dev pkg-config Compile ZNC

Now download and compile ZNC.

cd wget http://znc.in/releases/znc-1.4.tar.gz tar zxvf znc-1.4.tar.gz cd znc-1.4 ./configure --with-openssl make sudo make install Create a user

Create a separate ZNC user so that ZNC does not need to run as root:

sudo groupadd znc sudo adduser --system --home /var/lib/znc --group znc Configuring ZNC

You can use the interactive wizard to configure ZNC which really help create the initial configuration.

sudo -u znc /usr/local/bin/znc --datadir=/var/lib/znc --makeconf

Here is a transcript of how I answered the initial configuration questions.

[ .. ] Checking for list of available modules... [ >> ] ok [ ** ] Building new config [ ** ] [ ** ] First let's start with some global settings... [ ** ] [ ?? ] What port would you like ZNC to listen on? (1025 to 65535): 7778 [ ?? ] Would you like ZNC to listen using SSL? (yes/no) [no]: yes [ ?? ] Would you like ZNC to listen using both IPv4 and IPv6? (yes/no) [yes]: [ .. ] Verifying the listener... [ >> ] ok [ ** ] Unable to locate pem file: [/var/lib/znc/znc.pem], creating it [ .. ] Writing Pem file [/var/lib/znc/znc.pem]... [ >> ] ok [ ** ] [ ** ] -- Global Modules -- [ ** ] [ ** ] +-----------+----------------------------------------------------------+ [ ** ] | Name | Description | [ ** ] +-----------+----------------------------------------------------------+ [ ** ] | partyline | Internal channels and queries for users connected to znc | [ ** ] | webadmin | Web based administration module | [ ** ] +-----------+----------------------------------------------------------+ [ ** ] And 10 other (uncommon) modules. You can enable those later. [ ** ] [ ?? ] Load global module <partyline>? (yes/no) [no]: yes [ ?? ] Load global module <webadmin>? (yes/no) [no]: yes [ ** ] [ ** ] Now we need to set up a user... [ ** ] [ ?? ] Username (AlphaNumeric): yournick [ ?? ] Enter Password: [ ?? ] Confirm Password: [ ?? ] Would you like this user to be an admin? (yes/no) [yes]: [ ?? ] Nick [yournick]: [ ?? ] Alt Nick [yournick_]: [ ?? ] Ident [yournick]: [ ?? ] Real Name [Got ZNC?]: Your Name [ ?? ] Bind Host (optional): [ ?? ] Number of lines to buffer per channel [50]: 1024 [ ?? ] Would you like to clear channel buffers after replay? (yes/no) [yes]: [ ?? ] Default channel modes [+stn]: [ ** ] [ ** ] -- User Modules -- [ ** ] [ ** ] +--------------+------------------------------------------------------------------------------------------+ [ ** ] | Name | Description | [ ** ] +--------------+------------------------------------------------------------------------------------------+ [ ** ] | chansaver | Keep config up-to-date when user joins/parts | [ ** ] | controlpanel | Dynamic configuration through IRC. Allows editing only yourself if you're not ZNC admin. | [ ** ] | perform | Keeps a list of commands to be executed when ZNC connects to IRC. | [ ** ] | webadmin | Web based administration module | [ ** ] +--------------+------------------------------------------------------------------------------------------+ [ ** ] And 21 other (uncommon) modules. You can enable those later. [ ** ] [ ?? ] Load module <chansaver>? (yes/no) [no]: yes [ ?? ] Load module <controlpanel>? (yes/no) [no]: tes [ ?? ] Load module <controlpanel>? (yes/no) [no]: yes [ ?? ] Load module <perform>? (yes/no) [no]: yes [ ?? ] Load module <webadmin>? (yes/no) [no]: yes [ ** ] [ ?? ] Would you like to set up a network? (yes/no) [no]: [ ** ] [ ?? ] Would you like to set up another user? (yes/no) [no]: [ .. ] Writing config [/var/lib/znc/configs/znc.conf]... [ >> ] ok [ ** ] [ ** ]To connect to this ZNC you need to connect to it as your IRC server [ ** ]using the port that you supplied. You have to supply your login info [ ** ]as the IRC server password like this: user/network:pass. [ ** ] [ ** ]Try something like this in your IRC client... [ ** ]/server <znc_server_ip> +7778 flexiondotorg:<pass> [ ** ]And this in your browser... [ ** ]https://<znc_server_ip>:7778/ [ ** ] [ ?? ] Launch ZNC now? (yes/no) [yes]: no Running ZNV as a daemon

Here is a /etc/init.d/znc for Debian based on this installation method:

#! /bin/sh ### BEGIN INIT INFO # Provides: znc # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: ZNC IRC bouncer # Description: ZNC is an IRC bouncer ### END INIT INFO PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin DESC="ZNC daemon" NAME=znc DAEMON=/usr/local/bin/$NAME DATADIR=/var/lib/znc DAEMON_ARGS="--datadir=$DATADIR" PIDDIR=$DATADIR/run PIDFILE=$PIDDIR/$NAME.pid SCRIPTNAME=/etc/init.d/$NAME USER=znc GROUP=znc # Exit if the package is not installed [ -x "$DAEMON" ] || exit 0 # Read configuration variable file if it is present [ -r /etc/default/$NAME ] && . /etc/default/$NAME # Load the VERBOSE setting and other rcS variables . /lib/init/vars.sh # Define LSB log_* functions. # Depend on lsb-base (>= 3.2-14) to ensure that this file is present # and status_of_proc is working. . /lib/lsb/init-functions # # Function that starts the daemon/service # do_start() { # Return # 0 if daemon has been started # 1 if daemon was already running # 2 if daemon could not be started if [ ! -d $PIDDIR ] then mkdir $PIDDIR fi chown $USER:$GROUP $PIDDIR start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test --chuid $USER > /dev/null || return 1 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --chuid $USER -- $DAEMON_ARGS > /dev/null || return 2 } # # Function that stops the daemon/service # do_stop() { # Return # 0 if daemon has been stopped # 1 if daemon was already stopped # 2 if daemon could not be stopped # other if a failure occurred start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME --chuid $USER RETVAL="$?" [ "$RETVAL" = 2 ] && return 2 # Wait for children to finish too if this is a daemon that forks # and if the daemon is only ever run from this initscript. # If the above conditions are not satisfied then add some other code # that waits for the process to drop all resources that could be # needed by services started subsequently. A last resort is to # sleep for some time. start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON --chuid $USER [ "$?" = 2 ] && return 2 # Many daemons don't delete their pidfiles when they exit. rm -f $PIDFILE return "$RETVAL" } # # Function that sends a SIGHUP to the daemon/service # do_reload() { start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME --chuid $USER return 0 } case "$1" in start) [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME" do_start case "$?" in 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;; 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;; esac ;; stop) [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME" do_stop case "$?" in 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;; 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;; esac ;; status) status_of_proc -p $PIDFILE "$DAEMON" "$NAME" && exit 0 || exit $? ;; reload) log_daemon_msg "Reloading $DESC" "$NAME" do_reload log_end_msg $? ;; restart) log_daemon_msg "Restarting $DESC" "$NAME" do_stop case "$?" in 0|1) do_start case "$?" in 0) log_end_msg 0 ;; 1) log_end_msg 1 ;; # Old process is still running *) log_end_msg 1 ;; # Failed to start esac ;; *) # Failed to stop log_end_msg 1 ;; esac ;; *) echo "Usage: $SCRIPTNAME {status|start|stop|reload|restart}" >&2 exit 3 ;; esac

After you've created the script, you must give it the proper permissions to run and add the script to the startup/shutdown sequence.

sudo chmod 755 /etc/init.d/znc sudo update-rc.d znc defaults

Start the service:

sudo service znc start

Stop the service:

sudo service znc stop Web configuration

I love that ZNC comes bundled with a web based configuration tool. Just login to https://znc.example.org:7778 to add users, add networks to users and to add channels to networks. Really simple stuff.

IRC client configuration

I use HexChat, but other IRC clients are available. Just add a new Network to HexChat for your ZNC server, use the username, suffixed with the network name you configured in ZNC, and your ZNC password.

Conclusion

I much prefer ZNC to BIP.

  • I really like the web and IRC configuration but I still have the option to configure the config files directly.
  • ZNC is far less cryptic with regard to setting up IRC client connections and user management is much better implemented.
  • When I add a new channel to an existing network in ZNC it automatically appears in my connected clients without the need to restart anything.
  • ZNC's IRC backlogs don't have the confusing double time stamps present in BIP and ZNC is much faster re-establishing connections to my multiple IRC network and channels.
  • Most importantly, ZNC has been far more stable than BIP.

References

Categories: LUG Community Blogs

Steve Kemp: luonnos viesti - 31 heinäkuu 2014

Planet HantsLUG - Thu, 31/07/2014 - 13:54

Yesterday I spent a while looking at the Debian code search site, an enormously useful service allowing you to search the code contained in the Debian archives.

The end result was three trivial bug reports:

#756565 - lives

Insecure usage of temporary files.

A CVE-identifier should be requested.

#756566 - libxml-dt-perl

Insecure usage of temporary files.

A CVE-identifier has been requested by Salvatore Bonaccorso, and will be added to my security log once allocated.

756600 - xcfa

Insecure usage of temporary files.

A CVE-identifier should be requested.

Finding these bugs was a simple matter of using the code-search to look for patterns like "system.*>.*%2Ftmp".

Perhaps tomorrow somebody else would like to have a go at looking for backtick-related operations ("`"), or the usage of popen.

Tomorrow I will personally be swimming in a loch, which is more fun than wading in code..

Categories: LUG Community Blogs

Debian Bits: Jessie will ship Linux 3.16

Planet HantsLUG - Wed, 30/07/2014 - 22:10

The Debian Linux kernel team has discussed and chosen the kernel version to use as a basis for Debian 8 'jessie'.

This will be Linux 3.16, due to be released in early August. Release candidates for Linux 3.16 are already packaged and available in the experimental suite.

If you maintain a package that is closely bound to the kernel version - a kernel module or a userland application that depends on an unstable API - please ensure that it is compatible with Linux 3.16 prior to the freeze date (5th November, 2014). Incompatible packages are very likely to be removed from testing and not included in 'jessie'.

  1. My kernel module package doesn't build on 3.16 and upstream is not interested in supporting this version. What can I do?
    The kernel team might be able to help you with forward-porting, but also try Linux Kernel Newbies or the mailing list(s) for the relevant kernel subsystem(s).

  2. There's an important new kernel feature that ought to go into jessie, but it won't be in 3.16. Can you still add it?
    Maybe - sometimes this is easy and sometimes it's too disruptive to the rest of the kernel. Please contact the team on the debian-kernel mailing list or by opening a wishlist bug.

  3. Will Linux 3.16 get long term support from upstream?
    The Linux 3.16-stable branch will not be maintained as a longterm branch at kernel.org. However, the Ubuntu kernel team will continue to maintain that branch, following the same rules for acceptance and review, until around April 2016. Ben Hutchings is planning to continue maintenance from then until the end of regular support for 'jessie'.

Categories: LUG Community Blogs

Mick Morgan: punctuation matters

Planet ALUG - Mon, 28/07/2014 - 15:12

There is a nice tweet over at @NSA_PR. It reads:

We take your privacy, seriously.

Beyond parody.

Categories: LUG Community Blogs

Chris Lamb: start-stop-daemon: --exec vs --startas

Planet ALUG - Mon, 28/07/2014 - 14:15

start-stop-daemon is the classic tool on Debian and derived distributions to manage system background processes. A typical invokation from an initscript is as follows:

start-stop-daemon \ --quiet \ --oknodo \ --start \ --pidfile /var/run/daemon.pid \ --exec /usr/sbin/daemon \ -- -c /etc/daemon.cfg -p /var/run/daemon.pid

The basic operation is that it will first check whether /usr/sbin/daemon is not running and, if not, execute /usr/sbin/daemon -c /etc/daemon.cfg -p /var/run/daemon.pid. This process then has the responsibility to daemonise itself and write the resulting process ID to /var/run/daemon.pid.

start-stop-daemon then waits until /var/run/daemon.pid has been created as the test of whether the service has actually started, raising an error if that doesn't happen.

(In practice, the locations of all these files are parameterised to prevent DRY violations.)

Idempotency

By idempotence we are mostly concerned with repeated calls to /etc/init.d/daemon start not starting multiple versions of our daemon.

This might not seem to be particularly big issue at first but the increased adoption of stateless configuration management tools such as Ansible (which should be completely free to call start to ensure a started state) mean that one should be particularly careful of this apparent corner case.

In its usual operation, start-stop-daemon ensures only one instance of the daemon is running with the --exec parameter: if the specified pidfile exists and the PID it refers to is an "instance" of that executable, then it is assumed that the daemon is already running and another copy is not started. This is handled in the pid_is_exec method (source) - the /proc/$PID/exe symlink is resolved and checked against the value of --exec.

Interpreted scripts

However, one case where this doesn't work is interpreted scripts. Lets look at what happens if /usr/sbin/daemon is such a script, eg. a file that starts:

#!/usr/bin/env python # [..]

The problem this introduces is that /proc/$PID/exe now points to the interpreter instead, often with an essentially non-deterministic version suffix:

$ ls -l /proc/14494/exe lrwxrwxrwx 1 www-data www-data 0 Jul 25 15:18 /proc/14494/exe -> /usr/bin/python2.7

When this process is examined using the --exec mechanism outlined above it will be rejected as an instance of /usr/sbin/daemon and therefore another instance of that daemon will be incorrectly started.

--startas

The solution is to use the --startas parameter instead. This omits the /proc/$PID/exe check and merely tests whether a PID with that number is running:

start-stop-daemon \ --quiet \ --oknodo \ --start \ --pidfile /var/run/daemon.pid \ --startas /usr/sbin/daemon \ -- -c /etc/daemon.cfg -p /var/run/daemon.pid

Whilst it is therefore less reliable (in that the PID found in the pidfile could actually be an entirely different process altogether) it's probably an acceptable trade-off against the case of running multiple instances of that daemon.

This danger can be ameliorated by using some of start-stop-daemon's other matching tests, such as --user or even --name.

Categories: LUG Community Blogs

Chris Dennis: Website version control with Git

Planet HantsLUG - Sat, 26/07/2014 - 21:59

Some notes on using git to manage development and production versions of a website on a Linux server, based on Using Git to manage a web site.  There seem to be several web pages with similar ideas out there: I don’t know who wrote it down first.  And also with reference to Version Control with Git by Jon Lodger.

I’ve adapted those ideas for the way I like to do things:

  • I SSH in to the server, and do the editing there, using vim.
  • I have separate domains for development and production versions of my sites.  For the purposes of these notes, they’re called dev.example.org and www.example.org.  So the development version is also an active real-world website: my nginx configuration makes it only visible to me.
  • The document roots are /var/www/website and /var/www/website-dev respectively.
  • The ‘bare’ production git repository can be anywhere on the server.  I’ll put it at /var/www/website.git.  It’s a git convention to use the .git extension for bare repositories.

The steps for setting it up are as follows.  I’ll leave the setting of suitable permissions and use of sudo as an exercise for the reader.

  1. Put some web pages in /var/www/website-dev.
  2. mkdir /var/www/website cd /var/www/website-dev git init git add <all the appropriate files and directories> git commit -a -m "a message" mkdir /var/www/website.git cd /var/www/website.git git --bare init
  3. Create /var/www/website.git/hooks/post-receive containing:
#!/bin/bash GIT_WORK_TREE=/var/www/website git checkout -f
  • In the following, I’ve used ‘live’ as an alias for the production environment; you could use ‘prod’ or whatever you fancy.
  • chmod +x /var/www/website.git/hoots/post-receive cd /var/www/website-dev git remote add live file:///var/www/website.git git push live +master:refs/heads/master git push --set-upstream live master git push live
  • And, as if by magic, the files from the master branch of /var/www/website-dev are now in /var/www/website.
  • Then whenever you’ve got new code ready to into production, all that’s required is:
  • git push live
    Categories: LUG Community Blogs

    Steve Kemp: The selfish programmer

    Planet HantsLUG - Fri, 25/07/2014 - 14:16

    Once upon a time I wrote a piece of software for scheduling the classes available to a college.

    There was a bug in the scheduler: Students who happened to be named 'Steve Kemp' had a significantly higher chance (>=80% IIRC) of being placed in lessons where the class makeup was more than 50% female.

    This bug was never fixed. Which was nice, because I spent several hours both implementing and disguising this feature.

    I'm was a bad coder when I was a teenager.

    These days I'm still a bad coder, but in different ways.

    Categories: LUG Community Blogs
    Syndicate content