Tag - Sys Admin

Entries feed

Sunday, 30 August, 2015

Preview of switchconf 0.0.14-2 in Debian

There was a long time since I published the last version of switchconf.

This time someone requested that I add support for systemd by adding a service file. This service file does not make switchconf depend on systemd. It will still work with svs init scripts.

As my knowledge of systemd is minimal, please review my changes.

To download use the following entries:

switchconf_0.0.14-2_wip4_all.deb

switchconf_0.0.14-2_wip4.debian.tar.xz

switchconf_0.0.14-2_wip4.dsc

switchconf_0.0.14-2_wip4_amd64.changes

switchconf_0.0.14.orig.tar.xz

Saturday, 1 February, 2014

Collect and keeps up to date the system information using sysinfoupdate

In 2005 I was looking for ways to auto collect information about a Linux server. The information was to be used in case of bare bones recovery. I didn't found a satisfactory program so I created one, sysinfoupdate. This program have been growing long this years and now is a system that helps to maintain a diary of a Linux Installation. The diary records all the important changes the sysadmin does to the system. This records can be used during recovery after a broken hardware or to detect what change may be causing a malfunction, for example.

It's use is very simple, create a diario directory in your home directory, for example /root/diario, and then run sysinfoupdate. Inside diario you will find a group files with textual information about your system. It works best if you run it as superuser and you keep track of the changes under a version control system, like subversion or git.

You can download the Debian package here or download the source from here.

Monday, 12 November, 2012

Good hacks on using Debian testing

I found an interesting article on how to use Debian testing/unstable/experimental and ways to contribute back to Debian.

http://bonedaddy.net/pabs3/log/2012/10/29/thoughts-on-debian-testing/

Friday, 31 August, 2012

A Selection of talks from DebConf 2012

Monday, 6 February, 2012

A Selection of Talks from FOSDEM 2012.

It was only some days ago that I made the decision to go, for the first time to the FOSDEM (Free and Open Source Software Developers' European Meeting). That was a good decision. The keynotes and the maintracks were very good, with good presentations and contents.

It is a big conference and this year, is not an exception. With 429 speakers and 430 talks at 21 rooms in only two days. It's impossible to see all the presentations. The only 5 rooms with a video camcorder to tape the talk, where: Janson, K.1.105, Ferrer, H.1301, H.1302. It's very dificult to choose what talks to see, what talks to see later in video and what talks to loose. What I leave here is my selection of talks. This selection is representative of my tastes, not of the quality of the presentations. I will give links for material that is available now. I will do periodic updates when the new material is available, the video or the slides.

   Video
   Video
   Video
   Video
   Video
   Video
   Slides
   Video
   Video
   Video
   Video
   Video
   Slides

More resources:

http://lanyrd.com/2012/fosdem/

Tuesday, 3 January, 2012

To package or not to package, that's the question.

In the past I had to install many times, by hand, extra software on Unix machines, specially because of missing useful software like a C compiler or because I like too much to use the bash. In the end it can get very messy I promised myself to never do again a make install for manually installing software in a Debian machine.

It's possible and it pays on the long run. When you take a program from outside the distribution you need to: configure, compile, install and document what you have done. So you can do it again with the next version. Specially when you have done local modifications. If you put your software inside a Debian package and follow the most sensible Debian Policy rules you get:

  • The documentation on how to configure, build and install the software is in debian/rules file.
  • It's easy to upgrade or remove the software, because is a Debian package.
  • You can use a patch system like quilt or dpatch to isolate your local changes from the upstream sources. If you create different patches files, for every logical feature you enhance or fix, it will be easier to drop them when the new version have the desired feature and to know what features needs to be ported for the new version of the upstream software.
  • You can do it even with the binaries of proprietary software. Its easy to take an rpm or tar files with the binaries and insert them inside the sources of a Debian package. With the proper care it's easy to update the sources for the next upgrade.

For example I have been doing this for packaging the pristine upstream binary of eclipse, because the teachers of my University usually requests a newer version of eclipse than what is available from Debian stable or even unstable.

Another example is the support software for HP hardware before HP officially supported Debian. I have taken the original rpm files or the scexe scripts and convert them into a debian file. Usually I need only to change two files with every new release of software, the Makefile with the name of the new rpm file and the debian/changelog with the new version and what is new.

In the end it's easier than it seams to create and maintain a Debian package. It's a steep curve, but pays off on the long run.

The good thing is all this approaches are compatible with a puppet or chef system for managing the Unix servers.

page 2 of 2 -