Ten Essential Linux Admin Tools

10 outils (pouvant être) essentiels à l'administrateur système et réseaux Linux.

System Administrators (SAs) need a set of tools with which to manage their often unmanageable systems and environments*. These ten essential Linux administration tools provide excellent support for the weary SA. Those listed aren’t your standard list of tools deemed essential by industry bystanders. These are tools that have proven track records and have stood the test of time in the data center.

1. Webmin – Webmin is the ultimate web-based management platform for Linux and several other operating systems. Written in Perl, it simplifies and streamlines standard administrative tasks. Additionally, Webmin helps you configure very complex implementations of Apache, MySQL and SendMail. If you haven’t experienced Webmin, you should, it’s the essential administration tool.
2. byobu – If you’re a screen user, byobu is the next step. If you haven’t usedscreen, you should try byobu. Byobu is a Japanese word for the decorative screens or room dividers that often adorn Japanese homes. Hence, the name for a more decorative form of the screen utility. Linux people are nothing if not clever in their naming of projects.
3. tcpdump – It sounds crazy but you’d be surprised by how many times that System Administrators need to analyze network packets to help troubleshoot obscure problems that plague their systems. Tcpdump is the right tool for the job of analyzing network traffic. It isn’t beautiful or elaborate but it does exactly what its name advertises: It dumps IP-related traffic to the screen or to a file for analysis.
4. Virtual Network Computing (VNC) – In its many incarnations (TightVNC, UltraVNC,RealVNC), VNC has become one of the most readily recognized and widely utilized remote access tools in the System Administrator’s toolbox. Its broad acceptance is due in part to its platform-independence. VNC is easy to install, simple to configure and available for almost every contemporary operating system.
5. GNOME Partition Editor (GParted) – What’s better than fdisk? GParted. You have to love the power of this program, since you can boot to a Live CDROM and create, delete and resize your partitions without destroying any existing data. And, it works on almost every imaginable filesystem, even NTFS. For best results, download a Live CD/USB/PXE version and keep it handy.
6. DenyHosts – DenyHosts is a Python script that allows you to actively monitor your systems for attempted unauthorized logins via SSH and subsequently deny access to the originating host system. Denyhosts records the denied entries in/etc/denyhosts.conf. No System Administrator should bring up a system without it.
7. Nagios – Nagios is an extensive and somewhat complex network monitoring tool. It has the ability to monitor a variety of hosts, services and protocols. It is an enterprise class tool that is essential in every network regardless of size or complexity. With Nagios, you can monitor, alert, resolve and report on network problems. It also has trending and capacity planning capabilities. Nagios is an extrememly extensible tool through its plugins, addons, extensions and modules.
8. Linux Rescue CD – Numerous rescue CDs exist for every task or imaginable situation. There are a three notable standouts in the crowd for those of you who don’t have one of these in your arsenal: The Ubuntu Rescue Remix, Parted Magic and GRML. Ubuntu Rescue Remix is a command line-based data recovery and forensics tools compilation (CD or USB). Parted Magic is a super diagnostic and rescue CD/USB/PXE that contains extensive documentation. GRML is a Debian-based live CD that contains a collection of System Administrator tools for system rescue, network analysis or as a working Linux distribution.
9. Dropbox – Dropbox, as described in “Dropbox: Painless and Free Backup” is an essential backup and cross-platform file exchange tool. With Dropbox, you can leave home without your essential toolbox but still keep it with you where ever you go.
10. Darik’s Boot and Nuke (DBAN) – Described by its developers as “a self-contained boot disk that securely wipes the hard disks of most computers”, DBAN is an essential decommissioning tool for those who have to dispose of systems that are no longer in service. DBAN also assures System Administrators that data from any previous operating system installations will be unrecoverable. DBAN isn’t the fastest tool on the planet but it is very thorough and wipes all detectable disks securely and completely.

* It’s unfortunate that no set of tools exist to manage the unmanageable users in our midst.

(source : http://www.linux-mag.com/id/7870/)

FusionDirectory 1.0.4

Technologie FusionDirectory 1.0.4

Posté par Benoit Mortier (page perso, jabber id) le 07/11/12 à 01:40. Modéré par Pierre Jarillon. Licence CC by-sa

20

7

nov.

2012

L’équipe de FusionDirectory est heureuse de vous annoncer la publication de la version 1.0.4 de FusionDirectory. Pour ceux qui ne connaissent pas cet outil, sachez qu’il s’agit d’un gestionnaire d’infrastructure. Il vous permet de gérer via une interface Web :

• les utilisateurs : UNIX, Samba, informations administratives ;
• les groupes : UNIX, Samba ;
• les services : SMTP, IMAP/POP, DHCP, HTTP, dépôts Debian, DNS, antivirus, Asterisk ;
• les serveurs : déploiement via FAI/OPSI et paramétrage ;
• les postes clients : déploiement système et applications.

Plus de détails sur cette version 1.0.4 dans la suite de la dépêche.

• Site Web de FusionDirectory (628 clics)
• Documentation de FusionDirectory (54 clics)
• Forge de FusionDirectory (10 clics)
• Dépots de paquets pour distributions (26 clics)
• Téléchargement des sources (11 clics)
• FusionDirectory sur Freecode (10 clics)
• LinuxFr.org : annonce de Fusiondirectory 1.0.3 (12 clics)

La version 1.0.4 apporte son lot de corrections de bogues de la version 1.0.3, soit un nouveau framework « simple‐plugin » pour la création des greffons, un nouveau greffon et de nouvelles fonctionnalités.

Nouveau framework

Simple Plugin est la nouvelle façon d’écrire des greffons pour FusionDirectory. Il est désormais obligatoire et a été utilisé pour écrire les greffons Password Recovery et Board. Ce nouveau framework permet d’écrire des greffons de manière simple et lisible, en se concentrant sur ce que l’on veut faire et non sur le code à écrire.

Nouveau greffon

Board, est un petit tableau de bord pour FusionDirectory.

Autres nouveautés marquantes

• gestion de PHP 5.4, Smarty 3 et gettext ;
• suppression de la dépendance mdb2.php pour le cœur du logiciel ;
• retrait du code opsi obsolète des greffons ;
• l’espagnol, le vénézuélien et le néerlandais sont maintenant gérés ;
• guide d’aide à la réalisation d’un greffon avec le framework simple plugin ;
• adresse de courriel secondaire pour la récupération du mot de passe ;
• création de PC Windows à partir de l’interface ;
• visualisation de l’adresse MAC à côté de l’adresse IP dans la liste des systèmes ;
• ajout de quelques attributs à l’objet imprimante pour Windows dans le cadre d’une utilisation avec opsi ;
• mise à jour des fichiers LDIF recovery.ldif, goto.ldif, goserver.ldif, fdQuota.ldif et argonaut.ldif.

source: http://linuxfr.org/news/fusiondirectory-1-0-4

Simplify Your Life With an SSH Config File

Simplify Your Life With an SSH Config File

by jperras

If you’re anything like me, you probably log in and out of a half dozen remote servers (or these days, local virtual machines) on a daily basis. And if you’re even more like me, you have trouble remembering all of the various usernames, remote addresses and command line options for things like specifying a non-standard connection port or forwarding local ports to the remote machine.

Shell Aliases

Let’s say that you have a remote server named dev.example.com, which hasnot been set up with public/private keys for password-less logins. The username to the remote account is fooey, and to reduce the number of scripted login attempts, you’ve decided to change the default SSH port to 2200 from the normal default of 22. This means that a typical command would look like:

$ ssh fooey@dev.example.com -p 22000
password: *************

Not too bad.

We can make things simpler and more secure by using a public/private key pair; I highly recommend using ssh-copy-id for moving your public keys around. It will save you quite a few folder/file permission headaches.

$ ssh fooey@dev.example.com -p 22000
# Assuming your keys are properly setup...

Now this doesn’t seem all that bad. To cut down on the verbosity you could create a simple alias in your shell as well:

$ alias dev='ssh fooey@dev.example.com -p 22000'
$ # To connect:
$ dev

This works surprisingly well: Every new server you need to connect to, just add an alias to your .bashrc (or .zshrc if you hang with the cool kids), and voilà.

~/.ssh/config

However, there’s a much more elegant and flexible solution to this problem. Enter the SSH config file:

# contents of $HOME/.ssh/config
Host dev
    HostName dev.example.com
    Port 22000
    User fooey

This means that I can simply  $ ssh dev, and the options will be read from the configuration file. Easy peasy. Let’s see what else we can do with just a few simple configuration directives.

Personally, I use quite a few public/private keypairs for the various servers and services that I use, to ensure that in the event of having one of my keys compromised the dammage is as restricted as possible. For example, I have a key that I use uniquely for my github account. Let’s set it up so that that particular private key is used for all my github-related operations:

Host dev
    HostName dev.example.com
    Port 22000
    User fooey

Host github.com
    IdentityFile ~/.ssh/github.key

The use of IdentityFile allows me to specify exactly which private key I wish to use for authentification with the given host. You can, of course, simply specify this as a command line option for “normal” connections:

 $ ssh -i ~/.ssh/blah.key username@host.com

but the use of a config file with IdentityFile is pretty much your only optionif you want to specify which identity to use for any git commands. This also opens up the very interesting concept of further segmenting your github keys on something like a per-project or per-organization basis:

Host github-project1
    User git
    HostName github.com
    IdentityFile ~/.ssh/github.project1.key

Host github-org
    User git
    HostName github.com
    IdentityFile ~/.ssh/github.org.key

Host github.com
    User git
    IdentityFile ~/.ssh/github.key

Which means that if I want to clone a repository using my organization credentials, I would use the following:

$ git clone git@github-org:orgname/some_repository.git

Going further

As any security-conscious developer would do, I set up firewalls on all of my servers and make them as restrictive as possible; in many cases, this means that the only ports that I leave open are 80/443 (for webservers), and port 22 for SSH (or whatever I might have remapped it to for obfuscation purposes). On the surface, this seems to prevent me from using things like a desktop MySQL GUI client, which expect port 3306 to be open and accessible on the remote server in question. The informed reader will note, however, that a simple local port forward can save you:

$ ssh -f -N -L 9906:127.0.0.1:3306 coolio@database.example.com
# -f puts ssh in background 
# -N makes it not execute a remote command

This will forward all local port 9906 traffic to port 3306 on the remotedev.example.com server, letting me point my desktop GUI to localhost (127.0.0.1:9906) and have it behave exactly as if I had exposed port 3306 on the remote server and connected directly to it.

Now I don’t know about you, but remembering that sequence of flags and options for SSH can be a complete pain. Luckily, our config file can help alleviate that:

Host tunnel
    HostName database.example.com
    IdentityFile ~/.ssh/coolio.example.key
    LocalForward 9906 127.0.0.1:3306
    User coolio

Which means I can simply do:

$ ssh -f -N tunnel

And my local port forwarding will be enabled using all of the configuration directives I set up for the tunnel host. Slick.

Homework

There are quite a few configuration options that you can specify in~/.ssh/config, and I highly suggest consulting the online documentation or the ssh_config man page. Some interesting/useful things that you can do include: change the default number of connection attempts, specify local environment variables to be passed to the remote server upon connection, and even the use of * and ? wildcards for matching hosts.

I hope that some of this is useful to a few of you. Leave a note in the comments if you have any cool tricks for the SSH config file; I’m always on the lookout for fun hacks.

Source: http://nerderati.com/2011/03/simplify-your-life-with-an-ssh-config-file/

The State of Open-Source Monitoring

Source : https://speakerdeck.com/obfuscurity/the-state-of-open-source-monitoring