Archives de catégorie : Unix

Netbeans & Unity : ça marche presque tout seul

netbeans-ayatana-header

Dans un précédent article, je partageai un plugin Netbeans pour profiter du menu global du bureau Unity d’Ubuntu. Et bien chers amis, je vous le dis : n’installer plus ce plugin.

Ne vous inquiétez pas, je ne viens pas vous annoncer une nouvelle faille de sécurité dans ce plugin (c’est à la mode en ce moment). C’est juste que son utilisation n’est plus nécessaire car les dépôts officiels d’Ubuntu contiennent la librairie Ayatana qui s’appliquera à tout vos programme Java. Et oui, vous m’avez bien lu : « à tous vos programme Java ».

Si sur votre poste, on peut trouvez un browser Cassandra écrit en Java, un serveur bouchon SMTP écrit en Java, tous profiteront du menu centralisé et surtout de la recherche dans les menus.

Elle est pas belle la vie ? Comment on fait maintenant ?

Et bien rien si vous êtes passé à Ubuntu 15.04, c’est actif automatiquement.

Et pour les autres, restez concentré, ça va aller vite :

sudo add-apt-repository ppa:danjaredg/jayatana
sudo apt-get update
sudo apt-get install jayatana

Bien entendu, ça fonctionne aussi pour les non développeurs, ça fonctionne aussi avec jDownloader.

Ajouter un JDK dans Ubuntu

OpenJDKvsOracle

En suivant le fil de mes articles, vous devriez savoir que dispose d’un serveur dédié sous Ubuntu. Sur ce serveur , j’héberge un serveur Glassfish. Jusqu’à maintenant, je me suis obstiné à faire tourner ce conteneur JEE avec l’OpenJDK qui se trouve par défaut dans les dépôts officiel de mon système d’exploitation.

Aujourd’hui, je n’en peux plus, après de multiples crash système de la JVM (tous les 3 jours environs). Je ne possède pas une analyse fine de la cause mais avant de me lancer dans une analyse des fichiers « core » générés, je vais simplement tenter d’utiliser le JDK officiel d’Oracle. Même si la base de ce dernier est le premier, ce dernier peut contenir un patch pour ma situation…qui sait !

Télécharger le JDK

Je ne pensais pas que ce serait une difficulté mais ce n’est pas aussi évident de télécharger le JDK depuis le site d’Oracle directement sur le serveur avec la commande  » wget ». En effet, avant de pouvoir télécharger tout fichier, il faut passer par la case d’acceptation de la license Oracle. La parade à cet obstacle passe par l’utilisation d’un analyseur de de requête HTTP (comme Firebug sous Firefox).

Dans le navigateur, avant de lancer effectivement le téléchargement de l’archive, le serveur d’Oracle lance une série de redirection :

Capture du 2013-03-10 20:13:28

La dernière URL est de la forme « wget http://download.oracle.com/otn-pub/java/jdk/7u17-b02/jdk-7u17-linux-x64.tar.gz?AuthParam=1362942876_4bc4e1d256685c05747a32db3ca2d8ac ». C’est cette URL qu’il faut reprendre avec « wget ».

Installer le JDK

En soit, l’installation n’est pas compliqué, il suffit de décompresser l’archive téléchargée dans le répertoire de son choix (au hasard « /usr/lib/jvm »). Mais pour finir l’installation proprement, il est important d’ajouter le nouveau JDK dans la configuration des alternatives pour l’exécutable « /usr/bin/java ».

Sous Linux, la commande « alternatives » permet de maintenir des versions différentes pour des liens symboliques et de changer rapidement la cible du lient. L’ajout d’un JDK se fait donc simplement au travers de la commande :

update-alternatives --install /usr/bin/java java \
                /usr/lib/jvm/jdk1.7.0_17/bin/java 2000

Pour vérifier la bonne prise en compte, rien de plus simple, la commande ci-dessous vous donnera la liste des alternatives

update-alternatives --config java

Ce sites m’ont aidés à retrouver ces commandes et à comprendre de quoi s’agissait:
http://linuxdrops.cAom/install-glassfish-with-jdk-7-on-centos-rhel-fedora-debian-ubuntu/
http://linux.about.com/library/cmd/blcmdl8_alternatives.htm

Bien recevoir son serveur dédié (suite part 2)

J’ai dans mon panier 2 solutions à mes problèmes d’attaque de force brute sur ma connexion SSH :

  • le démon denyhosts
  • et, plus simplement, changer le port par défaut d’écoute de SSH

denyhosts

denyhosts, c’est un processus daemon qui scrute votre fichier de log où se trouve toutes les traces de tentatives de connexions. Toutes les hosts qui génèrent trop d’erreur de connexion seront blacklisté.

L’installation prend 2 secondes sous Ubuntu :

sudo apt-get install denyhosts

Et voilà, c’est fait et c’est fonctionnel. Vous trouverez les fichiers listant les tentatives suspicieuses de connexion dans :

/var/lib/denyhosts

Il ne restera plus qu’à compléter le fichier de configuration avec un serveur d’envoi des mails pour recevoir une alerte à chaque fois qu’une adresse est ostracisée.

Changer de port

Par défaut, SSH écoute sur le port 22. Il est facilement modifiable dans le fichier :

/etc/ssh/sshd_config

Puis par un simple arrêt / relance du démon SSH :

/etc/init.d/sshd restart

Vous devriez voir le nombre de tentative se réduire drastiquement.

Toutefois, il faut être vigilant sur cette dernière astuce (et sur celle qui consiste à empêcher l’utilisateur root de se connecter). Je ne sais pas comment ça se passe pour les autres hébergeur mais chez OVH, lorsqu’ils livrent un serveur, ils installent une clef pour pouvoir se connecter en root lorsqu’une intervention est nécessaire. Interdire l’utilisateur root ou changer le numéro de port rendra toute intervention de l’hébergeur impossible. Renseignez-vous bien auprès de ce dernier ou, au moins, ayez conscience que vous serez à bord et que si vous n’avez plus accès à votre machine, il n’y aura plus d’autre choix que de la réinstaller (d’où l’importance d’avoir un plan de sauvegarde bien roder 🙂 ).

Bien recevoir son serveur dédié (suite)

Où est-ce que j’en étais ? Ha oui, on a créé l’utilisateur qui va nous servir d’administration avec les droit sudo qui vont bien. C’est bien beau mais on peut encore protéger notre utilisateur root un peu plus. Et pour cela, on peut simplement empêcher les connexions à distance avec le compte root. Editer le fichier /etc/ssh/sshd_config et remplacer avec la valeur ci-dessous :

PermitRootLogin No

Ce qui est marrant, c’est que sans n’avoir encore rien fait de concret avec ce serveur, on peut voir les attaques de force brut pour se connecter avec des utilisateurs courant. Voici un extrait de mon /var/log/auth.log :

Nov 30 07:40:39 XXXXXXXX sshd[27464]: Failed password for root from 91.121.166.49 port 51087 ssh2
Nov 30 07:40:39 XXXXXXXX sshd[27466]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 30 07:40:39 XXXXXXXX sshd[27466]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ks360976.kimsufi.com  user=root
Nov 30 07:40:42 XXXXXXXX sshd[27466]: Failed password for root from 91.121.166.49 port 51305 ssh2
Nov 30 07:40:42 XXXXXXXX sshd[27468]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 30 07:40:42 XXXXXXXX sshd[27468]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ks360976.kimsufi.com  user=root
Nov 30 07:40:44 XXXXXXXX sshd[27468]: Failed password for root from 91.121.166.49 port 51640 ssh2
Nov 30 07:40:44 XXXXXXXX sshd[27470]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 30 07:40:44 XXXXXXXX sshd[27470]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ks360976.kimsufi.com  user=root
Nov 30 07:40:46 XXXXXXXX sshd[27470]: Failed password for root from 91.121.166.49 port 51833 ssh2
Nov 30 07:40:46 XXXXXXXX sshd[27472]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 30 07:40:46 XXXXXXXX sshd[27472]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ks360976.kimsufi.com  user=root

Ici, ce sont plusieurs tentative de connexion avec l’utilisateur root (d’où ma soudaine prise de conscience d’interdire tout accès root à distance). Des logs de ce genre, on y voit des utilisateur oracle, irc, nagios, postgres ou encore trac.

De ces observation, je vais en retirer 3 conclusions :

  • tout mot de passe de ce serveur sera complexe et généré par un outil du type keepass
  • lorsque j’installerai ma suite logiciel, je choisirai soigneusement et personnellement des noms d’utilisateur totalement atypique
  • avoir un serveur, aussi petit soit-il, ça rend paranoïaque ; le prochain article de ce serveur dédié portera très certainement sur un firewall

 

La puissance du côté négatif de la force

Le côté négatif, c’est tout simplement le caractère ‘‘ et la force, chez nous aujourd’hui, est la shell Unix. Ce fameux caractère dash est un fabuleux outil à plusieurs facettes. Connaître ses possibilité est au moins aussi (si ce n’est plus) essentiel que de connaître quelques raccourcis claviers (comprendre que ça vous fera gagner du temps. Après si vous êtes pas pressés dans la vie, vous pouvez passer votre chemin).

Le caractère dash comme représentation du dernier répertoire

C’est un classique, taper la commande suivante pour revenir dans le répertoire précédent

cd -

Par exemple :

[user@host:/etc]$ cd /var/log
[user@host:/var/log] cd -
[user@host:/etc] cd -
[user@host:/var/log] cd -
[user@host:/etc]
...

On ne remonte pas l’historique des répertoires mais on est bien content quand on se trouve dans la situation où on lance une application, on regarde les logs, on change une configuration, on relance, on vérifie les logs, on change une configuration, on relance, on vérifie les logs, … Cette boucle vertueuse se révèle bien plus rapide, avec un ‘cd –‘ et une (ou 2) commande(s) dans le presse papier.

Le caractère dash comme redirection d’entrée/sortie

C’est dans ce chapitre que la force nécessite du contrôle. Bien caché dans une commande le caractère ‘‘ représente une redirection d’un fichier vers la sortie standard ou inversement  de l’entrée standard vers un fichier. Les exemples suivant devraient illustrer mon propos. Imaginons que je sois en pleine rédaction de scripts pour archiver des fichiers de log ou manipuler ces mêmes archives. Basiquement pour archiver, j’utiliserai les commandes suivantes :

tar cf archives_20111116.tar *.log
bzip2 archives_20111116.tar

un inconvénient qui (devrait) saute(r) au yeux est l’utilisation de ce fichier archives_20111116.tar à la durée de vie très limitée et au moins de taille égale aux fichiers de logs que je veux archiver. Heureusement la caractère ‘-‘ est là pour nous sauver, on recommence et on remplace par :

tar cf - *.log | bzip2 > archives_20111116.tar.bz

Ici, la commande tar écrit sur la sortie standard au lieu d’écrire dans un fichier, il n’y a donc plus de fichier temporaire, tout transite en mémoire au fur et à mesure que la compression avance.

C’est pas tout, mais j’aimerai bien les décompresser moi ces archives mais sans les altérer et sans utiliser de fichier temporaire (comme à l’archivage en somme). Et bien, la force reste avec vous jusqu’au bout :

bzip2 -d archives_20111116.tar.bz | tar xf -

La commande tar lit l’entrée standard au lieu de lire le contenu d’un fichier. Je ne pense pas que vous vous rendiez compte de la magie qui se cache derrière ces manipulations ; l’exemple ici est plutôt simple et basique mais en gardant constamment cette fonctionnalité à l’esprit, on obtient des commandes puissantes en une seule ligne. Mon dernier exemple en date : une comparaison de fichier local et distant :

ssh user@host "cat /etc/hosts" | diff -wb /etc/hosts -

Le caractère dash comme délimiteur d’option

Sur une commande, tous les mots qui commence par ‘-‘ sont des options. A priori, je vous apprends rien. Mais alors comment se dépêtrer des noms de fichier qui commencent par ce même caractère ? Ou comment s’assurer que l’utilisateur n’ajoutera une option insidieusement au sein d’un de vos shell ? La réponse : le double dash ‘–‘. Le double dash indique la fin des options. Ceci signifie que tout ce qui se suit sur la commande ne sera pas considéré comme une option. Un exemple valant mieux qu’un long discours, voici comment faire pour supprimer un fichier nommé ‘-filename‘ :

rm -f -- -filename

Malheureusement, tout les shell n’implémente pas ce séparateur d’options et, à ma connaissance, seul le Bash le propose.

Allez, maintenant, il est temps de renouveler ce classique shell d’archivage et de sans cesse l’améliorer (comme ce qu’on devrait faire dans tout ce qu’on entreprend).

Bien recevoir son serveur dédié

Cette nuit, j’ai reçu un petit serveur dédié provisionné par Kimsufi/OVH avec une pré-installation Ubuntu. Il devrait me servir à mettre en place ma propre plate-forme d’intégration continue en Java et autre Grails…mais, je n’y suis pas encore ; j’y reviendrai sûrement.

Si vous commandez un de ces serveurs, sachez que la disponibilité affiché d’1 heure ne correspond à rien car, vous passerez par des étapes de validation de vos moyens de paiements. Pour ma part, ça a prit environ 7 heures mais si vous n’avez pas de chance, vous aurez des papiers à renvoyer pour validation.

Le serveur reçu est fourni avec un compte root et si il y a bien une habitude à ne pas prendre, c’est celle de ne pas utiliser quotidiennement ce compte mais d’en passer par un autre. Donc, on créé son compte utilisateur tout de suite :

useradd -m -d /home/moncompte moncompte
passwd moncompte

Maintenant, pour ne plus jamais avoir à utiliser ce compte (comme dans les installations par défaut d’Ubuntu), il faut configurer ce nouveau compte pour l’autoriser à faire des sudo. Rien de plus simple, il suffit d’appartenir au groupe sudo :

adduser moncompte sudo

Reconnectez vous avec votre nouveau compte fraîchement créé et mettez à jour votre distrib :

sudo apt-get update
sudo apt-get upgrade

Voici le minimum vital que j’ai appliqué dès réception. Et je vous conseille d’en faire autant et de ne jamais utiliser de telnet et de ftp, vous pouvez tous faire avec SSH.