Rercherche et suppression de fichier par critères sous Linux

Voici une mise en oeuvre de la commande « find » parmi tant d’autres.

Ici, je recherche tous les fichiers portant l’extension « .sql » ayant une date de création ou modification de plus de 15 jours. On peut facilement changer le dossier, la recherche, les options, ainsi que l’action à effectuer.

Voici le contenu de mon script Bash. Si vous faites comme moi, pensez à bien le rendre exécutable.

#!/bin/bash

# Suppression des sauvegardes MySQL de plus de 15 jours.
find /mnt/sauvegardes/*.sql -mtime +15 -exec rm {} ;

exit 0

Forcer un navigateur à récupérer un fichier Internet

Lors de la consultation de site sur Internet, le navigateur Internet (dit aussi « butineur ») met en cache des informations pour accélérer l’affichage d’un site lors d’une prochaine visite.
Il est aussi possible de toucher à la configuration de son serveur web (dans mon cas Apache) en activant et configurant le module « mod_expires ». Ce module permet de définir quel type de fichier est éligible à la mise en cache chez le client ainsi que la durée de conservation.

Oui mais voilà, malgré mes réglages côté serveur, la mise en cache se produit toujours de la même manière. Et n’est pas possible de toucher à la configuration côté client pour tout le monde …

Voici donc une petite alternative pour forcer le rechargement. Ici, on rajoute un morceau de chaine de caractères généré automatiquement au nom du fichier à télécharger. Le contenu du fichier restera le même, seule l’adresse va changer et passera de « http://127.0.0.1/mon_fichier.js » en « http://127.0.0.1/mon_fichier.js?ver=1338742725 ». Le numéro 1338742725 changera si une modification de contenu est faite sur le fichier, car la fonction PHP « filemtime » récupère la date de dernière modification du fichier.

Voici un exemple de mise en place de ce système dans une page PHP.

[html]<!DOCTYPE html>

<html lang="fr">

<head>
<title>Exemple</title>
<meta charset="utf-8" />
</head>

<body>
<div>
<h1>Mes fichiers</h1>
<ul>
<li><?php echo ‘<a href="mon_fichier.js?ver=’.filemtime("./mon_fichier.js").’">’; ?>Mon fichier</a></li>
</ul>
</div>
</body>

</html>[/html]

Reconfigurer le fuseau horaire d’une machine Debian

Pour redéfinir le fuseau horaire de sa machine tournant sous Debian, rien de plus simple, il faut reconfigurer le paquet « tzdata » à l’aide de la commande suivante.

dpkg-reconfigure tzdata

Répondez « Europe », puis « Paris », et constater le changement.

[generic]Current default time zone: ‘Europe/Paris’
Local time is now: Mon Jun 4 11:20:20 CEST 2012.
Universal Time is now: Mon Jun 4 09:20:20 UTC 2012.[/generic]

Pour recontrôler par la suite ces informations, il faut utiliser la commande « date ».
date

En retour, vous pourrez voir ceci. A noter la présence « (UTC+0200) » signifiant bien l’ajout de 2 heures par rapport au méridien de Greenwich.

[generic]root@debian:~# date
lundi 4 juin 2012, 11:24:28 (UTC+0200)[/generic]

Synchronisation via Unison

Qui n’a jamais perdu des fichiers faute de sauvegardes ? Faire des sauvegardes directement sur le même disque dur de la machine n’est pas non plus la meilleure idée.

Heureusement des outils comme Unison existent ! Unison à la différence de du célèbre RSync permet la synchronisation de répertoires de façon bidirectionnelle.

La procédure suivante demande une seconde machine sur laquelle copier les fichiers. Le transit des données se fera via une connexion SSH.

Récupération de la liste des paquets.
aptitude update

Installation du paquet.
aptitude install unison

Création du répertoire pour le stockage des journaux d’évènements.
mkdir -p /var/log/unison

Création du répertoire contenant les fichiers de configurations des synchronisations. Dossier à créer à la racine du répertoire personnel (ici « /root », sinon dans « /home/nom_utilisateur »).
mkdir -p /root/.unison

Création d’un fichier de configuration à placer dans le répertoire précédemment créé. A noter que l’extension est « .prf ».
[generic]### Racines ###

# Premier répertoire racine accessible en local.
root = /home/

# Second répertoire racine accessible via SSH.
root = ssh://root@1.1.1.1//home/

### Chemins à synchroniser ###

path = rep1/
path = rep2/

### Options ###

# La directive ‘silent’ active le fonctionnement totalement auto-
# matique, sans aucun message console.
silent = true

# La directive ‘fastcheck’ active la création d’un fichier conte-
# nant des "pseudo inodes numériques" des fichiers, évitant l’
# analyse complète du contenu des fichiers à synchroniser.
fastcheck = true

# La directive ‘times’ active la synchronisation des date de mo-
# dification de fichier.
times = true

# La directive ‘owner’ active la synchronisation de l’utilisateur
# propriétaire.
#owner = true

# La directive ‘group’ active la synchronisation du groupe pro-
# priétaire.
#group = true

# La directive ‘log’ active la journalisation.
log = true

# La directive ‘logfile’ définit l’emplacement du chemin complet
# du fichier de journalisation.
logfile = /var/log/unison/home.log
[/generic]

Appel à synchronisation via notre script. Il est possible que le client SSH demande une confirme lors de la connexion pour savoir s’il peut ajouter l’empreinte SSH de la machine distante, si tel est le cas répondez oui. Si vous avez une « passphrase », elle vous sera demandé aussi. Si vous avez besoin de savoir comment créer une clé SSH pour ce genre de pratique, rendez-vous ici : Génération d’une clé privée et publique SSH.
unison nom_du_script.prf

Génération d’une clé privée et publique SSH

Génération de la paire de clés. Libre à vous de définir une « passphrase » pour ajouter une protection supplémentaire lors de l’utilisation des clés.
ssh-keygen -t dsa -b 1024

Le répertoire caché « .ssh » présent à la racine du répertoire personnel (ici « /root ») contient maintenant deux fichiers :

  • « id_dsa » ne devra jamais être transmis ! Il est personnel, c’est la clé privée
  • « id_dsa.pub » peut être transmis sans crainte à des tiers de confiances, c’est la clé publique

Pour transmettre votre clé aux clients désirés, nous allons utiliser le script « ssh-copy-id ». Ce script aura pour but d’ajouter notre clé publique dans le fichier « ~/.ssh/authorized_keys ». Pour les plus courageux, sachez qu’il est possible de le faire sans le script.
ssh-copy-id -i ~/.ssh/id_rsa.pub ip-machine-distante

Maintenant, vous pourrez vous connecter sur la machine distante sans avoir à connaitre le mot de passe de l’utilisateur.
ssh root@ip-machine-distante

Gérer l’installation de paquets via l’APT-Pinning

Les paquets de la version « stable » de Debian sont certes stables, mais bien souvent datés. Il est néanmoins possible de forcer l’installation de paquet venant d’une autre branche (testing ou unstable).

Déclaration des nouveaux serveurs de paquets dans le fichier « /etc/apt/sources.list ».
[generic]## Stable
deb http://ftp.fr.debian.org/debian/ squeeze main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ squeeze main contrib non-free

## Unstable
deb http://ftp.fr.debian.org/debian/ wheezy main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ wheezy main contrib non-free

## Security
deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free
[/generic]

Mise à jour de la liste des paquets.
aptitude update

A partir de là, il faut savoir qu’il est possible existe une technique manuelle à la place de l’APT-Pinning. En ajoutant l’option « -t nom-version-debian » à la commande « aptitude install nom-paquet ».

Mais notre but est d’automatiser le traitement, alors créons le fichier « /etc/apt/preferences » avec la trame suivante. Le premier groupe est le choix par défaut lors de l’installation ou la mise à jour des paquets. Le deuxième groupe permet de forcer l’installer le paquet Unison issu de la branche unstable de Debian. On observe que la priorité est plus élevée que celle par défaut pour forcer sa sélection.
[generic]Package: *
Pin: release n=squeeze
Pin-Priority: 650

Package: unison
Pin: release n=wheezy
Pin-Priority: 700
[/generic]

La commande « aptitude versions nom-paquet » permet de voir la différence entre les versions (pour comparer plus en détails les différences de versions rendez-vous sur Debian Packages). On observe que par défaut le paquet stable sera installé à cause de sa priorité. Notre fichier « preferences » va changer tout ça lors des installations et des mises à jour.
[generic]root@serveur:~# aptitude versions unison
p 2.32.52-1 stable 650
p 2.40.63-2 testing 500[/generic]

Vérification du paquet candidat en regardant la version qui sera installée.
aptitude show nom-paquet

Sécuriser les VirtualHosts d’Apache grâce à GnuTLS

Installation des paquets nécessaires.
aptitude install gnutls-bin libapache2-mod-gnutls

Commençons par la création d’un répertoire de stockage pour les certificats. Le répertoire est donné à titre d’exemple, libre à vous de le changer.
mkdir -p /etc/certs/gnutls
cd /etc/certs/gnutls

Génération de la clé Diffie-Hellman
certtool --generate-dh-params --outfile dh.key

Création du modèle pour signer la clé. Dans mon cas, il s’appellera « ca.tpl » et aura ce contenu.
[generic]# X.509 Certificate options
#
# DN options

# The organization of the subject.
organization = "Mon entreprise"

# The organizational unit of the subject.
#unit = ""

# The locality of the subject.
locality = MaVille

# The state of the certificate owner.
state = "Région"

# The country of the subject. Two letter code.
country = FR

# The common name of the certificate owner.
cn = "CA"

# A user id of the certificate owner.
#uid = "clauper"

# If the supported DN OIDs are not adequate you can set
# any OID here.
# For example set the X.520 Title and the X.520 Pseudonym
# by using OID and string pairs.
#dn_oid = "2.5.4.12" "Dr." "2.5.4.65" "jackal"

# This is deprecated and should not be used in new
# certificates.
# pkcs9_email = "none@none.org"

# The serial number of the certificate
serial = 2012013001

# In how many days, counting from today, this certificate will expire.
expiration_days = 1825

# X.509 v3 extensions

# A dnsname in case of a WWW server.
#dns_name = "*.societe.fr"

# An IP address in case of a server.
#ip_address = "192.168.1.1"

# An email in case of a person
#email = "none@none.org"

# An URL that has CRLs (certificate revocation lists)
# available. Needed in CA certificates.
crl_dist_points = "http://societe.fr/ca-crl.crt"

# Whether this is a CA certificate or not
ca

# Whether this certificate will be used for a TLS client
#tls_www_client

# Whether this certificate will be used for a TLS server
#tls_www_server

# Whether this certificate will be used to sign data (needed
# in TLS DHE ciphersuites).
#signing_key

# Whether this certificate will be used to encrypt data (needed
# in TLS RSA ciphersuites). Note that it is preferred to use different
# keys for encryption and signing.
#encryption_key

# Whether this key will be used to sign other certificates.
cert_signing_key

# Whether this key will be used to sign CRLs.
crl_signing_key

# Whether this key will be used to sign code.
#code_signing_key

# Whether this key will be used to sign OCSP data.
#ocsp_signing_key

# Whether this key will be used for time stamping.
#time_stamping_key

# Whether this key will be used for IPsec IKE operations.
#ipsec_ike_key
[/generic]

Génération de la clé d’autorité (CA). Cette clé est la plus importante et ne devra jamais être divulguée !
certtool --generate-privkey --outfile ca.key
certtool --generate-self-signed --load-privkey ca.key --template ca.tpl --outfile ca.crt

Changement des droits sur la clé d’autorité.
chmod 600 ca.key
chown root:root ca.key

Génération du clé privée pour Apache.
certtool --generate-privkey --outfile apache.key

Création du modèle pour signer la clé. Dans mon cas, il s’appellera « apache.tpl » et aura ce contenu.
[generic]# X.509 Certificate options
#
# DN options

# The organization of the subject.
organization = "Mon entreprise"

# The organizational unit of the subject.
#unit = ""

# The locality of the subject.
locality = MaVille

# The state of the certificate owner.
state = "Région"

# The country of the subject. Two letter code.
country = FR

# The common name of the certificate owner.
cn = "Apache"

# A user id of the certificate owner.
#uid = "clauper"

# If the supported DN OIDs are not adequate you can set
# any OID here.
# For example set the X.520 Title and the X.520 Pseudonym
# by using OID and string pairs.
#dn_oid = "2.5.4.12" "Dr." "2.5.4.65" "jackal"

# This is deprecated and should not be used in new
# certificates.
# pkcs9_email = "none@none.org"

# The serial number of the certificate
serial = 2012013002

# In how many days, counting from today, this certificate will expire.
expiration_days = 1825

# X.509 v3 extensions

# A dnsname in case of a WWW server.
dns_name = "*.societe.fr"

# An IP address in case of a server.
#ip_address = "192.168.1.1"

# An email in case of a person
#email = "none@none.org"

# An URL that has CRLs (certificate revocation lists)
# available. Needed in CA certificates.
#crl_dist_points = "http://societe.fr/ca-crl.crt"

# Whether this is a CA certificate or not
#ca

# Whether this certificate will be used for a TLS client
#tls_www_client

# Whether this certificate will be used for a TLS server
tls_www_server

# Whether this certificate will be used to sign data (needed
# in TLS DHE ciphersuites).
#signing_key

# Whether this certificate will be used to encrypt data (needed
# in TLS RSA ciphersuites). Note that it is preferred to use different
# keys for encryption and signing.
#encryption_key

# Whether this key will be used to sign other certificates.
#cert_signing_key

# Whether this key will be used to sign CRLs.
#crl_signing_key

# Whether this key will be used to sign code.
#code_signing_key

# Whether this key will be used to sign OCSP data.
#ocsp_signing_key

# Whether this key will be used for time stamping.
#time_stamping_key

# Whether this key will be used for IPsec IKE operations.
#ipsec_ike_key
[/generic]

Génération du certificat pour les sites d’Apache. Normalement tout est automatisé, aucune interaction ne sera nécessaire.
certtool --generate-certificate --load-privkey apache.key --load-ca-certificate ca.crt --load-ca-privkey ca.key --template apache.tpl --outfile apache.crt

Génération du fichier de contrôle des certificats révoqués.
certtool --generate-crl --load-ca-privkey ca.key --load-ca-certificate ca.crt --outfile ca-crl.crt

Génération d’un certificat pour permettre l’importation plus facile dans un navigateur.
certtool -i --infile ca.crt --outder --outfile x509-ca.crt

Désactivation du module OpenSSL s’il est déjà actif, pour mettre GnuTLS à la place.
a2dismod ssl
a2enmod gnutls

Modifier le fichier de configuration d’un VirtualHost que l’on souhaite sécuriser. Voici le contenu d’un de mes fichiers.
[generic]<VirtualHost *:443>

GnuTLSEnable on
GnuTLSPriorities NORMAL:!DHE-RSA:!DHE-DSS:!AES-256-CBC:%COMPAT
GnuTLSDHFile /etc/certs/gnutls/dh.key
GnuTLSClientCAFile /etc/certs/gnutls/ca.crt
GnuTLSCertificateFile /etc/certs/gnutls/apache.crt
GnuTLSKeyFile /etc/certs/gnutls/apache.key

ServerName test.societe.fr:443

DocumentRoot /var/www/test

<Directory /var/www/test>
Options SymLinksIfOwnerMatch
AllowOverride All
Order Allow,Deny
Allow from All
</Directory>

LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/error-test.log
CustomLog ${APACHE_LOG_DIR}/access-test.log combined

</VirtualHost>[/generic]

Il ne reste plus qu’à recharger le démon Apache pour prendre en compte nos modifications.
service apache2 reload

Réinitialiser le mot de passe Superviseur d’Internet Explorer suite à un oubli

Lorsque vous tenter d’aller sur Internet avec Internet Explorer, il se peur qu’une fenêtre popup vous invite à saisir le mot de passe du superviseur. Cette fonction permet de restreindre l’accès à Internet aux utilisateurs non autorisés.

Sans ce mot de passe, vous pouvez vous aussi être privé de votre dose quotidienne d’information numérique … Mais heureusement il est possible de le réinitialiser facilement.

  1. Ouvrir regedit.exe en tant qu’administrateur
  2. Chercher la branche suivante : hkey_local_machine\software\microsoft\windows\currentversion\policies\ratings
  3. Supprimer la clé KEY
  4. Redémarrer votre ordinateur
  5. Constatez le changement

Libre à vous de redéfinir un mot de passe, ou de rester sans.

Attribuer les rôles FSMO à un autre contrôleur de domaine Active Directory

Il existe cinq rôles FSMO (Flexible Single Master Operations) dans une forêt Active Directory :

  • Contrôleur de schéma – Un détenteur du rôle de contrôleur par forêt. Le détenteur du rôle FSMO de contrôleur de schéma est le contrôleur de domaine chargé de mettre à niveau le schéma d’annuaire.
  • Maître d’attribution de noms de domaine – Un détenteur du rôle de maître par forêt. Le détenteur du rôle FSMO de maître d’attribution de noms de domaine est le contrôleur de domaine chargé de modifier l’espace de noms du domaine dans toute la forêt de l’annuaire.
  • Maître d’infrastructure – Un détenteur du rôle de maître par domaine. Le détenteur du rôle FSMO de maître d’infrastructure est le contrôleur de domaine chargé de mettre à jour l’identificateur de sécurité (SID) et le nom unique d’un objet dans une référence d’objet entre domaines.
  • Maître RID – Un détenteur du rôle de maître par domaine. Le détenteur du rôle FSMO de maître RID est le contrôleur de domaine unique chargé de traiter les demandes du pool RID provenant de tous les contrôleurs de domaine d’un domaine particulier.
  • Émulateur PDC – Un détenteur du rôle de maître par domaine. Le détenteur du rôle FSMO d’émulateur PDC est un contrôleur de domaine Windows 2000 qui se proclame contrôleur principal de domaine auprès des postes de travail, serveurs membres et contrôleurs de domaine de versions antérieures. Il agit aussi comme l’explorateur principal du domaine et traite les incohérences de mots de passe.

Voici la procédure à suivre pour changer le contrôleur de domaine responsable des rôles FSMO :

  1. Ouvrez une session sur le contrôleur de domaine actuellement responsable des rôles FSMO. L’utilisateur connecté doit être membre du groupe :
    • Administrateurs d’entreprise pour pouvoir transférer les rôles de contrôleur de schéma ou de maître d’opérations des noms de domaine ;
    • Administrateurs de domaine du domaine pour les rôles d’émulateur PDC, de maître RID et de maître d’infrastructure.
  2. Ouvrez une invite de commande, puis tapez ntdsutil avant de valider par Entrée,
  3. Tapez roles, puis appuyez sur Entrée,
    Remarque : Pour afficher la liste des commandes disponibles aux invites de l’utilitaire ntdsutil, tapez ? et appuyez sur Entrée.
  4. Tapez connections et appuyez sur Entrée,
  5. Tapez connect to server nom_serveur, puis appuyez sur Entrée, où nom_serveur est le nom du contrôleur de domaine auquel vous souhaitez assigner le rôle FSMO,
  6. À l’invite server connections, tapez q, puis appuyez sur Entrée,
  7. Tapez transfer nom_rôle, où nom nom_rôle est le rôle à transférer,
    Pour afficher une liste des rôles que vous pouvez transférer, tapez ? à l’invite fsmo maintenance, puis appuyez sur Entrée, ou consultez la liste des rôles fournie au début de cet article. Par exemple, pour transférer le rôle de maître RID, tapez transfer rid master.
  8. À l’invite fsmo maintenance, tapez q, puis appuyez sur Entrée pour accéder à l’invite ntdsutil. Tapez q, puis appuyez sur Entrée pour quitter Ntdsutil.

Pour ensuite contrôler la bonne prise en compte des rôles, vous pouvez-vous donner un coup d’oeil sur cet article.

Tester si un site est totalement hors ligne

Il peut arriver que lorsque vous tentez de rejoindre un site celui ci semble injoignable, mais l’est-il réellement ? Le problème peut venir d’ailleurs comme une mauvaise résolution DNS, un problème de routage, etc …

Un petit site sur le net permet de le tester pour vous, ainsi vous aurez deux sons de cloches ; s’il n’y arrive pas non plus, alors le site est probablement indisponible.

Rendez-vous sur http://downforeveryoneorjustme.com/ pour tester tout ça.