LUG Community Blogs

Steve Kemp: Free (orange) SMS alerts

Planet HantsLUG - Tue, 05/08/2014 - 10:56

In the past I used to pay for an email->SMS gateway, which was used to alert me about some urgent things. That was nice because it was bi-directional, and at one point I could restart particular services via sending SMS messages.

These days I get it for free, and for my own reference here is how you get to receive free SMS alerts via Orange, which is my mobile phone company. If you don't use Orange/EE this will probably not help you.

The first step is to register an Orange email-account, which can be done here:

Once you've done that you'll have an email address of the form example@orange.net, which is kinda-sorta linked to your mobile number. You'll sign in and be shown something that looks like webmail from the early 90s.

The thing that makes this interesting is that you can look in the left-hand menu and see a link called "SMS Alerts". Visit it. That will let you do things like set the number of SMSs you wish to receive a month (I chose "1000"), and the hours during which delivery will be made (I chose "All the time").

Anyway if you go through this dance you'll end up with an email address example@orange.net, and when an email arrives at that destination an SMS will be sent to your phone.

The content of the SMS will be the subject of the mail, truncated if necessary, so you can send a hello message to yourself like this:

echo "nop" | mail -s "Hello, urgent message is present" username@orange.net

Delivery seems pretty reliable, and I've scheduled the mailbox to be purged every week, to avoid it getting full:

Hostnamepop.orange.net UsernameYour mobile number PasswordYour password

If you wished to send mail from this you can use smtp.orange.net, but I pity the fool who used their mobile phone company for their primary email address.

Categories: 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
Syndicate content