Databases, Systems & Networks

Recently the hard drive in my mac mini running Mac OSX Leopard (10.5) failed. Luckily I had time machine backing it up to an external USB disk. Now, since I had to replace the drive and rebuild my system anyway I figured, why not upgrade to Snow Leopard? Planning to just pull what I needed off the backup drive manually I went ahead with the upgrade. There aren’t too many files on this machine that I depend on. Just some ssh keys, gpg keys and random documents scattered about here and there. So I upgraded, installed my apps and copied my files from the backup. Everything was going smoothly until I tried to actually write to one of the files I copied from the backup drive. This is when I started getting permission errors.

Here’s what happened when I tried to update my ssh known_hosts file:

airbag:~ keith$ echo foo > .ssh/known_hosts 
-bash: .ssh/known_hosts: Permission denied

Huh? But I own this file…dont I?

airbag:~ keith$ id
uid=501(keith) gid=20(staff) groups=20(staff),402(com.apple.sharepoint.group.1),204(_developer),100(_lpoperator),98(_lpadmin),81(_appserveradm),80(admin),79(_appserverusr),61(localaccounts),12(everyone),401(com.apple.access_screensharing)

airbag:~ keith$ ls -al .ssh/known_hosts 
-rw-r--r--@ 1 keith 502 56140 Mar 25 2009 .ssh/known_hosts

Well, as it turns out I forgot to look at the file ACLs…

airbag:~ keith$ ls -le .ssh/known_hosts 
-rw-r--r--@ 1 keith 502 56140 Mar 25 2009 .ssh/known_hosts
 0: group:everyone deny write,delete,append,writeattr,writeextattr,chown

Well no wonder, the ACL is set to deny write,delete,append,writeattr,writeextattr and chown from everyone! Let’s get rid of that.

airbag:~ keith$ sudo chmod -N .ssh/known_hosts 
Password:

That ought to do it. The -N flag says get rid of all the ACL info on the file. You could also update this to be just right for your user or group but I’d rather use only the standard unix permissions.

airbag:~ keith$ ls -le .ssh/known_hosts 
-rw-r--r--@ 1 keith 502 56140 Mar 25 2009 .ssh/known_hosts

Seems to have removed all ACLs from the file. I wonder if we can write to it now…

airbag:~ keith$ echo foo >> .ssh/known_hosts 
airbag:~ keith$

And there you have it, the file is writable once again. Now its time to get some real work done!

Most hardcore command line users and unix geeks love vi, but I prefer nano. If you want to change your default crontab editor to nano, here’s how to do this:

For a one time edit, launch the terminal and type:

EDITOR=nano crontab -e

If you want to set nano as your default editor in general, you use this command:

export EDITOR=nano

Now when you go to edit crontab, nano will be the default editor than vi. You can test this by typing:

crontab -e

Looking beyond Mac OS X, this should work in Linux as well.

Parfois que nous avons besoin de vous connecter via SSH à un autre ordinateur, nous trouvons que cet ordinateur que nous comptions SSH dans (ce que nous allons appeler « destiny ») peuvent utiliser NAT et, par conséquent, il doesn ' t compte avec une adresse IP publique que nous pourrions utiliser pour se connecter à lui, ou il peut être derrière un pare-feu qui a gagné ' t permettent l'accès de l'extérieur.

Si le « destin » peut réussir à établir une connexion SSH vers un autre ordinateur qui n'est accessible, nous pouvons utiliser ce deuxième ordinateur afin d'établir un tunnel SSH inverse à notre ordinateur « destiny », nous allons appeler ce deuxième ordinateur « origine » (même si elle n'est pas réellement l'ordinateur que nous allons utiliser pour gérer à distance les « cibles », mais qu'un pont).

Un tunnel SSH inverse fonctionne en connectant « destinée » à « l'origine » et puis en se servant cette connexion SSH dans « destin » de n'importe quel ordinateur connecté à « l'origine ». Ce tunnel SSH inverse devrait fonctionner dans la plupart des distributions Linux sans problème.

Alors, laisse supposer que nous avons à présent deux ordinateurs :

« L'origine » IP : aaa.bbb.ccc.ddd

« Destiny » IP : inconnue ou non disponible

Tout d'abord, nous établissons la connexion SSH de "destinée" à « l'origine », qui permet la fonctionnalité SSH inverse avec le paramètre – r :

SSH r 61999:localhost:22 origin_user@aaa.bbb.ccc.ddd

Le premier nombre (61999) indique quel port on va pour utiliser « origine » pour vous connecter à « destiny », localhost est le nom de domaine que nous utiliserons pour cela aussi bien, et le dernier numéro (22) indique quel port est le « destin » écouter pour SSH.

Une fois que cette connexion est établie, et être connecté à le "origine" (peu importe si nous sommes connectés local ou à distance), nous pouvons établir la connexion au « destin » :

SSH p 61999 destiny_user@localhost

Effectivement, nous pouvons utiliser un ordinateur avec un accès SSH permanent comme un pont entre des ordinateurs qui ne sont pas autrement accessibles par l'intermédiaire de SSH. N'importe quel ordinateur connecté à le « origine » peut se connecter à autres ordinateurs avec inversion de tunneling SSH activé.

Source: tuto-linux.com

Sur Linux, ne vous est-il jamais arrivé de vouloir chercher une chaîne de caractères dans un dossier complet, autrement dit une multitude de fichiers ?

Et bien croyez-moi, si un jour vous devez chercher une adresse email, une adresse IP, un bout de code, ou autre, dans plusieurs milliers de fichiers, cette commande vous épargnera un gros travail manuel.

Placez vous dans le répertoire dans lequel vous souhaitez rechercher une chaîne de caractères. Et tapez la commande suivante :

find . -name "*" -exec grep -Hn "trouvemoi" {} \;

En remplaçant trouvemoi par ce que vous cherchez.

Par exemple, si vous cherchez une adresse IP dans tous vos fichiers logs à la fois, vous ferez (ne tapez que ce qui se trouve après le #) :

monlinux / # cd /var/log
monlinux log # find . -name "*" -exec grep -Hn "192.168.0.1" {} \;

Une autre technique consiste à utiliser “rgrep” qui va effectuer un “grep” récursif à partir du dossier dans lequel on se trouve et dans toute l’arborescence descendante.

La remontée d’alerte par SMS (“Short Message Service”) est un plus non négligeable dans le monitoring de systèmes d’informations critiques.

Les services gratuits permettant d’utiliser les SMS depuis le système restent rare.

Depuis plusieurs années déjà, “Google Agenda” propose à ses clients des rappels de rendez-vous par SMS.
Rapidement, ce service Google fût détourné pour être utilisé comme source de remontée d’alertes (exemple : “SmsAlert : Envoyer des SMS gratuitement depuis ses serveurs” sur le site Macsim’s Mind qui utilisait le script PHP d’ Alexander Skakunov pour remonter des alertes par SMS).

Bien que très efficaces, la plupart de ces détournement sont implémentés en PHP qui n’est pas installé sur tous les serveurs.

L’idée de cet article et d’utiliser la même technique mais implémentée en BASH.

Principe de fonctionnement

Le principe est de créer un événement dans un agenda Google Calendar débutant dans 5 minutes et X secondes et d’avertir l’administrateur par SMS 5 minutes avant le début de l’événement. Le SMS sera donc envoyé après X secondes.

L’objectif du script “googalert” (disponible sur sourceforge) est de n’utiliser que des commandes classiques du shell, de pouvoir choisir l’agenda dans lesquels seront stockés les alertes et d’être parfaitement conforme à l’API Google(http://www.udel.edu/CIS/software/dist/google/calendar/java.client/gdata/doc/calendar.htmlvoir Add an event).

Lire la suite…