Cette opération se révèle extrêmement facile sur un système Gnu/Linux puisqu’il suffit de créer un point de montage sur le système et d’autoriser son accès via la configuration d’Apache:

Monter le lecteur réseau automatiquement via fstab (y ajouter la ligne suivante):

//192.168.0.10/apache /mnt/netdrive smbfs rw,user,uid=1000,gid=1000,credentials=/etc/samba/pub.cred 0 0

user = n’importe quel utilisateur peut monter et démonter le partage
uid,gid = à qui appartient le partage (par défaut root.root avec les droits 755 donc un utilisateur ne peut écrire par défaut dans le partage)
credentials = on met pas l’utilisateur et le mot de passe en clair dans fstab mais dans un fichier /etc/samba/pub.cred (protégé en lecture lui)

le fichier pub.cred contient:
username=Domain\Apache
password=motdepasseassocie

source: Monter un partage Samba avec fstab de Jérome Hanoteau

Configurer les droits d’accès depuis Apache (/etc/apache2/sites-available/default ou autre), il faut ajouter les lignes suivantes (à adapter) entre les balises VirtualHost souhaitées:

1
2
3
4
5
6
7

Alias /netdrive/ "/mnt/netdrive/"
<Directory "/mnt/netdrive/">
    Options -Indexes MultiViews FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

En revanche sous Windows, impossible d’accéder à un lecteur réseau depuis Apache avec une configuration par défaut. Et pour cause, par défaut le serveur Apache est lancé en tant que service par l’utilisateur « System », or cet utilisateur ne peut accéder aux partages réseaux.

La solution apparait donc simplement, il suffit de modifier le compte avec lequel le serveur Apache est lancé. Il faut remplacer l’utilisateur « System » par un utilisateur du domaine ayant les droits nécessaires sur les répertoires concernés. Pour la suite nous utiliserons donc l’utilisateur « domain\Apache ».

Les étapes:

• Win+R
• Services.msc
• Clic droit sur « Apache »
• Onglet « Log on »
• Modifier le compte comme sur l’image ci-contre
• Valider

• Ajouter les droits sur les répertoires nécessaires au fonctionnement d’Apache pour cet utilisateur:
  • C:\Program Files\Apache Software Foundation\Apache2.2
  • C:\Windows\temp

Pour ajouter les droits sur un répertoire, il faut effectuer un clic droit sur celui-ci puis « Propriétés » puis dans l’onglet « Security », ajouter l’utilisateur souhaité et lui donner les droits souhaités (lecture, écriture pour les répertoires locaux nécessaires à Apache, lecture et/ou écriture pour les lecteurs réseaux en fonction des besoins).

Il faut également effectuer cette opération sur les répertoires réseaux que l’on souhaite lui rendre accessible.

/!\ !!! Nous touchons ici à la gestion des droits d’accès, veillez à ne pas fournir trop de droits à cet utilisateur afin de limiter l’impact en cas d’erreur dans la configuration (utiliser un utilisateur de base de votre domaine et ne lui donner accès qu’aux répertoires nécessaires). !!! /!\

N’oublions pas de relancer le service Apache une fois ces modifications effectuées afin de valider le fonctionnement du serveur avec ce nouvel utilisateur.

Nous passons ensuite à la configuration d’Apache à proprement parler, comment rendre accessible ce fameux lecteur réseaux ?

Contrairement à ce que l’on pourrait penser, il est impossible de dire à Apache d’utiliser un lecteur réseau identifié par une lettre. De même, la gestion des droits à ce répertoire doit se faire au niveau Windows et non dans la configuration d’Apache.

Ainsi au niveau de la configuration d’Apache lui-même, rien de spécial. Il est possible d’ajouter un alias pour faciliter les choses mais ce n’est pas obligatoire.

Alias /netdrive/ « //192.169.0.10/apache/ »

Il suffit ensuite d’utiliser soit le chemin réel, soit l’alias dans notre code PHP ou autre afin d’accéder à ces données.

Exemple:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?php
// Affiche le contenu d'un fichier sur le réseau et déplace celui-ci
$rep = "//192.169.0.10/apache/";
$annee = date("Y");
$dest_rep = "//192.169.0.10/apache/$annee";
$dir = opendir($rep);
while ($f = readdir($dir))
{
   if(is_file($rep.$f))
   {
     echo $f;
     rename($rep.$f, $dest_rep.$f);
   }
}
?>

Squid peut être configuré en tant que « Proxy » (comportement par défaut), il permet dans ce cas à ses utilisateurs d’accéder à tout ou partie d’internet ou de divers Intranet. Il peut également servir de « Reverse-Proxy » , il permet alors de rendre disponible certaines ressources internes (provenant d’un ou plusieurs serveurs) tout en proposant une mise en cache, ce qui va alléger la charge des serveurs situés derrière lui.

Schéma du principe de fonctionnement du Reverse-Proxy:

Par défaut, une seule instance de squid peut être lancée à la fois. Si l’on souhaite mettre en oeuvre un Proxy et un Reverse-Proxy sur un même serveur, il va falloir procéder à quelques modification dans la configuration de squid.

Nous n’allons pas nous occuper ici de la configuration de Squid en mode Proxy puisque la configuration par défaut permet déjà ce fonctionnement. Nous allons donc permettre le lancement de multiples instances et configurer le Reverse-Proxy.

Nous allons donc avoir 2 fichiers de configurations différents:

/etc/squid/squid.conf
/etc/squid/squid-reverse.conf

Voyons un exemple de ce que peut donner la configuration du fichier squid-reverse.conf:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# nom du reverse-proxy et port d'écoute
visible_hostname test
http_port 80 defaultsite=192.168.0.5
#
# le site proposé par défaut par le reverse-proxy se trouve sur 192.168.0.5:
cache_peer 192.168.0.5 parent 80 0 no-query no-digest originserver name=test
acl webserver dst 192.168.0.5
http_access allow webserver
#
# autoriser l'utilisation du reverse-proxy sur le port 80 pour tout le monde:
acl all src 0.0.0.0/0.0.0.0
http_access allow all
acl web port 80
http_access allow web
#
# configuration du cache:
cache_dir ufs /var/spool/squid3 2048 16 256
coredump_dir /var/spool/squid3
cache_effective_group proxy
cache_mem 50 MB
minimum_object_size 0 KB
maximum_object_size 64096 KB
#
# Emplacement du PID et des fichiers de logs:
pid_filename /var/run/squid-reverse.pid
access_log /var/log/squid/access-reverse.log squid
cache_log /var/log/squid/cache-reverse.log
#
forwarded_for on

Nous devrons ensuite générer le cache correspondant à ces 2 configurations:

/usr/sbin/squid -z

/usr/sbin/squid -z -f /etc/squid/squid-reverse.conf

Puis modifier le script de lancement de squid, ou en ajouter un pour les gérer indépendamment, nous allons ajouter un fichier:

/etc/init.d/squid-reverse

Pour faire simple et tester, il suffit d’y placer la commande de lancement suivante:

/usr/sbin/squid -f /etc/squid/squid-reverse.conf

Libre à vous ensuite de créer un véritable script de lancement en vous basant sur le script de lancement de Squid ou sur le template disponible (« /etc/init.d/skeleton« ).

Lancer ces scripts automatiquement au démarrage pour démarrer le Proxy et le Reverse-Proxy:

update-rc.d -f squid defaults

update-rc.d -f squid-reverse defaults

Nos 2 services ne devant pas être utilisés par les mêmes personnes, le proxy sera utilisé depuis le réseau interne tandis que le reverse-proxy sera utilisé par les internautes souhaitant accéder à notre site, nous penserons également à configurer un parefeu à l’aide d’iptables afin de sécuriser ce serveur proxy, un exemple suivra dans le prochain article.

Sources et ressources relatives:

• Configurer de multiples instances de Squid
• Configurer Squid en Reverse-Proxy
• Installer et configurer Squid sous Ubuntu

1
2
3
4

  <"pre" lang="html" line="1" file="download.html" colla="+">
    <p>Texte à afficher</p>
  </"pre">
  <!--(Ne pas mettre les guillemets autour de pre)-->

Liste des différentes options:

• lang: Langage du code utilisé
• file: Nom du fichier généré pour téléchargement
• line: Ligne à partir de laquelle le contenu doit être affiché
• colla: + pour maximiser par défaut, +/- pour minimiser par défaut

Seul le langage utilisé est obligatoire pour bénéficier de la coloration syntaxique fournie par le plugin. Les autres paramètres sont facultatifs.

Lorsque je me suis connecté à mon compte gmail depuis Thunderbird, j’ai eu droit au message d’erreur suivant:

Web login required: http://mail.google.com/support/bin/answer.py?answer=78754

Afin de régler le problème et pouvoir à nouveau accéder à votre compte depuis votre logiciel de messagerie, il suffit de vous rendre à l’adresse indiquée puis de saisir votre mot de passe ainsi que le captcha associé, cela déverrouille l’accès IMAP si pour une quelconque raison cette sécurité se serait mise en place.

Vous devriez ensuite pouvoir vous connecter sans problème.

Hors sur mon laptop, je n’ai pas de port série (db9). J’ai donc trouvé un adaptateur usb => db9.

Afin de l’utiliser sous Linux, il suffit de charger le bon module.

Ici il me suffit donc de charger le module pl2303 à chaque démarrage afin de pouvoir l’utiliser.

Charger manuellement ce module:

modprobe pl2303 ou insmod pl2303 (selon votre distribution)

Charger automatiquement ce module au démarrage:

echo pl2303 | sudo tee -a /etc/modules

(permet d’ajouter pl2303 au fichier /etc/modules)

Une fois cet adaptateur reconnu, nous pouvons l’utiliser directement via le périphérique /dev/ttyUSB0.

Il est possible d’utiliser Putty avec le port indiqué (/dev/ttyUSB0) mais étant sous Linux, il est également possible d’utiliser directement les TTY (ces consoles accessibles via CTRL+ALT+Fx).

Voici donc la manipulation à effectuer:

cd /etc/event.d

sudo cp tty1 ttyS0

Éditer le fichier ttySo via vim, nano ou votre éditeur favori:

Remplacez la dernière ligne par : exec /sbin/getty ttyUSB0 9600

Lorsque votre site web est en phase de développement ou lorsque vous souhaitez que votre site reste privé, n’apparaisse pas dans les résultats des moteurs de recherche, une solution très simple et rapide à mettre en place existe.

Il suffit de placer à la racine de votre site, un fichier « robots.txt » contenant quelques directives à l’attention des robots que ceux-ci explorent votre site en quête de pages à référencer ou dans le cas de robots malicieux, en quête de fichiers spécifiques.

Ce petit fichier permet donc de contrôler l’indexation du contenu de nos site web par les moteurs de recherches.

Voici un tableaux avec quelques directives et leur utilité:

Le chemin des répertoires ou fichiers concernés peuvent ne pas être totalement définis afin de masquer le nom de ceux-ci.

Les noms des robots sont disponibles sur robotstxt.org

Pour aller plus loin, n’oubliez pas de limiter l’accès à vos données sensibles en verrouillant leur accès via un fichier .htaccess et une protection par mot de passe sur ces répertoires.

Ces directives n’ont pas nécessairement besoin d’apparaître dans un fichier robots.txt pour être appliquées. Il faut donc être très prudent dans leur utilisation.

voici aujourd’hui un lien vers un article de qualité permettant à tous de comprendre le principe du multiplexage ainsi que son intérêt dans l’utilisation d’ SSH.

SSH est un protocole incontournable, à la fois parce que c’est une manière fiable et sécurisée pour accéder à des machines quand on n’a qu’une confiance limitée dans le réseau qui va acheminer nos messages, et aussi parce qu’il peut servir de transport pour d’autres protocoles non sécurisés.

Cet article va aborder une fonctionnalité très utile d’OpenSSH et de la version 2 du protocole pour partager des connexions.

Même si ce n’est pas une nouveauté (la première implémentation est apparue dans OpenSSH version 3.9p1), c’est fichtrement commode, et une petite explication de texte n’est pas totalement superflue.

Lire la suite de cet article sur UnixGarden.

je me suis aperçu il y a peu de temps que mon lecteur DVD et mon graveur ne fonctionnait plus correctement sous Ubuntu.

Ceux-ci fonctionnent parfaitement lorsque je démarre mon PC mais plus par la suite. Ainsi, après un CD gravé, les lecteurs ne semblent plus reconnus par Ubuntu.

Pour ceux qui rencontreraient ce type de problème, une solution simple consiste à désactiver le support de l’acpi au boot.

Il suffit pour cela d’ajouter l’argument suivant à votre séquence de démarrage:

noapic

• Pour les utilisateurs de Grub, ceci est à ajouter à la fin de la ligne kernel du fichier /boot/grub/menu.lst
• Pour les utilisateurs de Grub2, il suffit d’ajouter cet argument à la ligne GRUB_CMD_LINUX_DEFAULT= du fichier /etc/default/grub puis d’executer la commande update-grub afin de prendre en compte ces modifications.

Ayant déjà traité ce sujet ici pour Ubuntu jusqu’à Jaunty, je rouvre le sujet de l’activation de ces cartes sous Ubuntu 9.10.

Des modifications ont été apportées entre ces 2 versions d’Ubuntu. Ainsi sous Karmic Koala, le module acerhk n’existe plus.

Cependant un nouveau module le remplace, acer-wmi.

Cette manipulation est valable pour tout Linux ayant un kernel ≥ 2.6.31. Seules les commandes pour charger les modules peuvent différer d’un OS à un autre.

Il suffit de charger ce module pour activer votre carte WiFi:

sudo modprobe acer-wmi

Le fait de décharger ce module via la commande rmmod ne désactive pas la carte.

De même concernant le pilote WiFi, il est possible d’utiliser directement le module ath5k:

sudo modprobe ath5k

Ainsi les commandes permettant d’activer / désactiver votre carte WiFi en utilisant l’acpi ne fonctionnent plus.

Pour automatiser l’activation de votre carte au démarrage de votre machine, il suffit donc d’ajouter ces 2 modules dans le fichier suivant:

/etc/modules

acer-wmi

ath5k

Mise à jour concernant la possibilité d’activer / désactiver la carte sans éteindre le pc:

Concernant l’activation / désactivation manuelle de cette carte, il existe une solution, tout comme cela était faisable avec acerhk, il suffit de modifier la valeur dans le bon fichier.

Ici ce fichier est le suivant:

/sys/devices/platform/acer-wmi/rfkill/rfkill1/state

Comme auparavant,

echo 0 > /sys/devices/platform/acer-wmi/rfkill/rfkill1/state permet de désactiver la carte

echo 1 > /sys/devices/platform/acer-wmi/rfkill/rfkill1/state permet de d’activer la carte

Le tout avec les droits root et xxxpath étant l’emplacement indiqué précedemment.

Grub2 est installé par défaut sur Ubuntu 9.10 Karmic Koala. Voilà pourquoi je pense que cet article devrait aider pas mal de monde.

Tandis que Grub utilisait le fichier /boot/grub/menu.lst comme fichier de configuration, Grub2 utilise quant à lui 2 fichiers:

/boot/grub/grub.cfg

/etc/default/grub

Le premier contient les données nécessaires au démarrage des différents systèmes tandis que le second permet de configurer les options de Grub2 telles que:

L’affichage ou non du menu: GRUB_HIDDEN_TIMEOUT

La durée de cet affichage: GRUB_TIMEOUT

La résolution par défaut de Grub: GRUB_GFXMODE

Une fois ce fichier modifié, n’oubliez pas d’exécuter un update-grub afin de prendre en compte celles-ci.

Il se peut également que tous vos systèmes n’aient pas été reconnus. Dans ce cas, une commande s’impose:

os-prober

Cette commande permet de rechercher tous les systèmes d’exploitations présents sur vos disques durs.

Et pour terminer,

update-grub

Cette commande permet de régénérer le fichier /boot/grub/grub.cfg en prenant en compte les modifications apportées par os-prober.

Si vous désirez effectuer des modifications directement dans /boot/grub/grub.cfg, la syntaxe est compréhensible et similaire à celle de Grub.

Voici les différentes lignes à retrouver pour chacun de vos systèmes d’exploitations Linux:

set root=(hd0,x) //indique la racine de votre système

linux /vmlinuz… //indique l’emplacement du kernel

initrd /initrd.img-… //indique l’emplacement du système minimal permettant d’amorcer le démarrage

Vous avez maintenant en main tout le nécessaire afin de configurer votre Grub2 correctement. Si vous avez d’autres suggestions pour ce paramétrage, merci de les mettre à disposition en commentaire.