Nov 3, 2012
Exactly one week ago I was attending the Fedora Activity Day organized in Milan in concomitance with the Linux Day event being organized in several italian cities. Meeting the Fedora italian team has been simply great, we’ve been collaborating remotely since more than an year now and finding out all them being so friendly and pleasant has been a great pleasure.
Each of us presented a specific Fedora-related topic (I personally talked about Fedora and its Infrastructure, my presentation is publicly viewable at the following link) and I must admit everyone did an awesome job, we taught and learnt from each other at the same time and given the fact it was the very first time the team was put together, well, I can say our mission was accomplished.
Unfortunately something didn’t work as expected and the number of visitors that joined our event was very limited. The lack of marketing is apparently one of the most common problems within Linux and its derivative distributions especially when it comes to attending specific events. I feel our event’s concomitance with the Linux Day was one of the main causes, especially when the LuG (Linux User Group) behind the event sponsors a distribution which is not the same as the one you promote. I’m pretty much sure there is a lot of space for improvements but the team is still very young and a lot of work will be put together to improve our next events, that said I would like to thank Gabriele Trombini and Marina Latini for taking the time and efforts for organizing everything in an awesome location like Milan is.
We also had the luck to have a Gnomer sitting in one of the chairs of the Politecnico‘s classroom where we were presenting our Fedora activities: Paolo Borelli, the father of Gedit and one of the most active GNOME developers. His first question right after meeting up? “hey Andrea, given the fact CIA.vc is dead, are you going to set up a KGB istance sooner or later for GNOME? being a sysadmin has never been easy :-)
Oct 6, 2012
Logging in into a Linux machine and executing the hundreds commands available is just one of the most common usages of OpenSSH. Another interesting and very useful usage is tunneling some specific (or even all) traffic from your local machine to an external machine you have access to.
Today we’ll analyze how to access a certain virtual machine’s console by tunneling the relevant VNC port locally and accessing it through your favorite VNC client. The scenario:
- Machine A is our main virtualization machine and hosts several virtual machines. (VMs)
- Each VM has its own VNC port assigned. (usually the port range goes from 5900 to 5910 or even more if the hosted VMs are more than 10)
- We’ll be using libvirt, thus virsh.
We first need to find out which port got assigned to the VM we want to have console access to:
sudo virsh
virsh # list
Id Name Status
----------------------------------------------------
5 foo running
6 bar running
7 foobar running
virsh # vncdisplay foobar
:3
We, then, create a tunnel which redirects all the traffic from the main virtualization machine’s port to the port we gonna specify in the next command:
ssh -f -N -L 5910:localhost:5903 user@machine-A.com
A few details about the previous command:
- **-N **tells SSH to not execute any command after logging in.
- -f tells SSH to hide into the background just before the command gets executed.
- -L enables the port forwarding between the local (client) host and the host on the remote side.
And…why did I choose respectively port 5903 and 5910
While you can adjust port 5910 with your own choice (that will just move the tunneled traffic from port 5910 to your favorite port), that won’t work as expected with port 5903 since each VNC port is binded to the number of display virsh assigned to it. (for example, the bar VM may be running on display 5, thus its vncdisplay port will be 5905)
When done, fire up your favorite VNC client and create a new connection with the following details:
Protocol: VNC - Virtual Network Computing
Server: localhost - 127.0.0.1
Port: 5910
The connection will load and you’ll be put in front of your ‘foobar’ VM console.
Sep 19, 2012
È con piacere che annuncio la mia presenza al Fedora Activity Day di Milano in data 27 Ottobre 2012 e con altrettanto piacere ringrazio gli organizzatori per avermi dedicato uno spazio di trenta minuti in cui discutere ed approfondire le tematiche derivanti dall’amministrazione di sistemi Linux, nello specifico, dell’amministrazione degli stessi computer che ospitano e rendono disponibili numerosi servizi alle migliaia di utenti Fedora che contribuiscono quotidianamente al progetto.
Ho partecipato fisicamente, purtroppo, a pochissimi eventi Open Source e per questo motivo sono particolarmente emozionato di aver la possibilità di prender parte ad una manifestazione così sentita ed apprezzata come il Linux Day, contesto in cui lo stesso Fedora Activity Day prenderà piede. Le aspettative sono tante e mi impegnerò in modo tale da presentare al pubblico il maggior numero di strumenti e attività inerenti all’amministrazione di sistemi Linux, il tutto con la speranza di invogliare il maggior numero dei presenti a contribuire allo stesso progetto Fedora.
A titolo introduttivo elenco alcuni dei punti su cui mi soffermerò durante il mio talk:
- Quali sono i principi fondamentali a cui l’infrastruttura Fedora si ispira.
- Chi c’è dietro all’infrastruttura Fedora, quante persone e con quali competenze, quali sono i mezzi di comunicazione.
- Quanti e quali Datacenter permettono al progetto Fedora di funzionare.
- Quali sono i software utilizzati, come vengono utilizzati e con quali strumenti il team Infrastruttura provvede alla manutenzione dei sistemi fisici e virtuali disponibili, come vengono monitorati i server Fedora e molto altro!
Con la speranza di una partecipazione numerosa, vi rimando alla pagina dedicata all’evento.
Sep 17, 2012
Today I’ll be telling you about an interesting way to build your Debian packages using Deb-o-Matic, a tool developed and maintained by Luca Falavigna. Some more details about this tool from the package’s description:
Deb-o-Matic is an easy to use build machine for Debian source packages based on pbuilder, written in Python.
It provides a simple tool to automate build of source packages with limited user interaction and a simple configuration. It has some useful features such as automatic update of pbuilder, automatic scan and selection of source packages to build and modules support.
The setup.
Download the package.
apt-get install debomatic
Modify the main configuration file as follows:
[default]
builder: pbuilder
packagedir: /home/john/debomatic # Take note of the following path since we'll need it for later use.
configdir: /etc/debomatic/distributions
pbuilderhooks: /usr/share/debomatic/pbuilderhooks
maxbuilds: 3 # The number of builds you can perform at the same time.
inotify: 1
sleep: 60 # The sleep time between one build and another.
logfile: /var/log/debomatic.log
[gpg]
gpg: 0 # Change to 1 if you want Deb-O-Matic to check the GPG signature of the uploaded packages.
keyring: /etc/debomatic/debomatic.gpg # Add the GPG Keys you want Deb-O-Matic to accept in this keyring.
[modules]
modules: 1 # A list of all the available modules will follow right after.
modulespath: /usr/share/debomatic/modules
[runtime]
alwaysupdate: unstable experimental precise
distblacklist:
modulesblacklist: Lintian Mailer
mapper: {'sid': 'unstable',
'wheezy': 'testing',
'squeeze': 'stable'}
[lintian]
lintopts: -i -I -E --pedantic # Run Lintian in Pedantic mode.
[mailer] # You need an SMTP server running on your machine for the mailer to work. You can have a look at the 'Ssmtp' daemon which is a one-minute-setup MTA, check an example over <a href="https://github.com/averi/config-files/blob/master/backups/offlineimap%20%2B%20ssmtp%20%2B%20imapfilter/ssmtp.conf" target="_blank">here</a>.
fromaddr: debomatic@localhost
smtphost: localhost
smtpport: 25
authrequired: 0
smtpuser: user
smtppass: pass
success: /etc/debomatic/mailer/build_success.mail-template # Update the build success or failure mails as you wish by modifying the relevant files.
failure: /etc/debomatic/mailer/build_failure.mail-template
[internals]
configversion = 010a
The available modules are:
- “Contents“, which acts as a ‘dpkg -c’ over the built packages.
- “DateStamp“, which displays build start and finish times into a file in the build directory.
- “Lintian“, which stores Lintian output on top of the built package in the pool directory.
- “Mailer“, which sends a reply to the uploader once the build has finished.
- “PrevBuildCleaner“, which deletes all files generated by the previous build.
- “Repository“, which generates a local repository of built packages.
Configure ‘dput‘ to upload package’s sources to your local repository, edit the /etc/dput.cf file and add this entry:
[debomatic]
method = local
incoming = /home/john/debomatic
or the following if you are going to upload the files to a different machine through SSH:
[debomatic]
login = john
fqdn = debomatic.example.net
method = scp
incoming = /debomatic
Add a new Virtual Host on Apache and access the repository / built packages directly through your browser:
<VirtualHost *:80>
ServerAdmin john@example.net
ServerName debomatic.example.net
DocumentRoot /home/john/debomatic
<Directory /home/john/debomatic>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
<Directory>
</VirtualHost>
Start the daemon:
sudo /etc/init.d/debomatic start
(Optional) Add your repository to APT‘s sources.list:
deb http://debomatic.example.net/ unstable main contrib non-free
(Optional) Start Deb-O-Matic at system’s startup by modifying the /etc/init.d/debomatic file at line 21:
- [ -x "$DAEMON" ] || exit 0
- [ "$DEBOMATIC_AUTOSTART" = 0 ] && exit 0
+ [ -x "$DAEMON" ] || exit 0
+ [ "$DEBOMATIC_AUTOSTART" = 1 ] && exit 0
and finally add it to the desired runlevels:
update-rc.d debomatic defaults
Enjoy!
Sep 15, 2012
Ever wondered how you can update your website (in our case a static website with a bunch of HTML and PHP files) by committing to a Git repository hosted on a different server? if the answer to the previous question is yes, then you are in the right place.
The scenario:
and a few details about why would you opt for maintaining your website through Git:
- You need multiple people to access the static content of your website and you also want to maintain all the history of changes together with all the Git’s magic.
- You think using an FTP server is not secure enough.
- You think giving out SSH access or more permissions on the server to multiple users it’s not what you want. (also using scp will overwrite the files directly with all its consequences)
the setup, on server A:
Clone the Git repository over the directory that your Web server will serve.
cd /srv/www.domain.com/http && sudo git clone http://git.example.com/git/domain.git
Grab the needed package:
apt-get install fishpolld or yum install fishpolld
Set up a “topic” (called website_update) that will call a ‘git pull‘ each time the repository hosted on server B receives an update. (the file has to be placed into the /etc/fishpoll.d directory)
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
WEBSITEDIR="/srv/www.domain.com/http"
if [ -d "${WEBSITEDIR}" ]; then
cd "${WEBSITEDIR}"
else
echo "Unable to access theme directory. Failing."
exit 1
fi
git pull
Add a little configuration file that will enable the website_update‘s topic at daemon’s startup. (you should name it website_update.conf)
[fishpoll]
on_start = True
Open the relevant port on Iptables so that server A and server B can communicate as expected, the daemon runs over** port 27527**.
-A INPUT -m state --state NEW -m tcp -p tcp -s <strong>server-B-IP</strong> --dport 27527 -j ACCEPT
Start the daemon. (by default, logs are sent to syslog but you can run the daemon in Debug mode by using the -D flag)
sudo /etc/init.d/fishpolld start or sudo systemctl start fishpolld.service or sudo /usr/sbin/fishpolld -D
and on server B:
Grab the needed package:
apt-get install fishpoke or yum install fishpoke
Configure the relevant Git hook (post-update, located into the hooks directory) and make it executable.
#!/bin/sh
echo "Triggering update of configuration on server A"
fishpoke server-A-IP-or-DNS website_update
Finally test the whole setup by committing to the repository hosted on server B and verify your changes being sent live on your website!