Par défaut, Gforge limite de le nom de domaine de l’email à 16 caractères,

donc on est bloqué lors de la creation de l’utilisateur à cause de l’adresse mail.

Pour palier à ce problème, il faut modifier  le fichier /opt/gforge/common/include/User.class

Se placer dans la fonction « setNewEmailAndHash »

et modifier le chiffre de 16 à 25 .

ex fichier :

—————————————————————————————————————————

function setNewEmailAndHash($email, $hash= ») {

if (!$hash) {
$hash = substr(md5(strval(time()) . strval(mt_rand())), 0, 25);
}
——————————————————————————————————————————

Je viens de trouver un blog sympa qui parle d’administration système et qui contient une rubrique consacrée  aux serveurs ESXi (astuces, tests…)

Il s’agit de http://www.synergeek.fr/blog/tag/esxi/

En quelques mots: la 3G+ est basée sur la technologie HSDPA (High Speed Downlink Packet Access), la 3G+ est une évolution technologique du réseau 3G, cela permet d’augmenter les débits de navigation et de téléchargement.

Pour un meilleur résultat, j’ai désactivé dans le bios les ports que je n’utilise pas (ports com), cela me faisait un conflit d’IRQ avec ma carte 3G. Vérifier la présence du programme wvdial (installé par défaut sur toutes les distri) qui permet de créer la connexion modem. Sous Root taper « wvdial » si vous n’avez pas de réponse installer le parquet sinon mettre la carte 3G dans le port PCMCIA. Puis regarder le fichier messages pour voir les drivers que la carte utilise.

Extrait du fichier messages
# tail -10 /var/log/messages:

————————————————————————————————————————————————————————————————–
Apr 20 15:57:10 test-laptop kernel: [16923.068000] pccard: CardBus card inserted into slot 0
Apr 20 15:57:11 test-laptop kernel: [16923.536000] Initializing Nozomi driver 2.1 (build date: Apr 15 2007 05:40:45)
Apr 20 15:57:11 test-laptop kernel: [16923.540000] nozomi 0000:04:00.0: Card type is: 2048
Apr 20 15:57:11 test-laptop kernel: [16923.540000] PCI: Enabling device 0000:04:00.0 (0000 -> 0002)
Apr 20 15:57:11 test-laptop kernel: [16923.540000] ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 19 (level, low) -> IRQ 19
Apr 20 15:57:11 test-laptop kernel: [16923.540000] nozomi 0000:04:00.0: Nozomi driver nozomi_tty
Apr 20 15:57:11 test-laptop kernel: [16923.540000] nozomi 0000:04:00.0: Version of card: 3
Apr 20 15:57:11 test-laptop kernel: [16923.540000] nozomi 0000:04:00.0: Initialization OK!
————————————————————————————————————————————————————————————————–

Ici, nous voyons bien que notre système a installé le driver nozomi, il faudra donc mettre /dev/noz0 pour le nom du périphérique du

modem.

En Root :

# vim /etc/wvdial.conf

——————————————————————————-

[Dialer SFR]
Modem = /dev/noz0
Baud = 460800
FLOWCONTROL= NOFLOW
Init1 = ATZ
Init2 = AT&F&D2&C1S0=0
Init3 = AT+CGDCONT=1, »IP », »websfr »
Phone = *99***1#
Username = vodafone
Password = vodafone
Ask Password = 0
Dial Command = ATD
Stupid Mode = 1
Idle Seconds = 3000
Auto DNS = 1

——————————————————————————–
Enregistrer puis quitter.

Lancer la connexion:

Toujours en Root:

# wvdial SFR

Résultat:

–> WvDial: Internet dialer version 1.54.0
–> Initializing modem.
–> Sending: ATZ
ATZ
OK
–> Sending: AT&F&D2&C1S0=0
AT&F&D2&C1S0=0
OK
–> Sending: AT+CGDCONT=1, »IP », »websfr »
AT+CGDCONT=1, »IP », »websfr »
OK
–> Modem initialized.
–> Idle Seconds = 3000, disabling automatic reconnect.
–> Sending: ATD*99***1#
–> Waiting for carrier.
ATD*99***1#
CONNECT 57600
–> Carrier detected. Starting PPP immediately.
–> Starting pppd at Tue Apr 3 16:52:00 2007
–> pid of pppd: 21251
–> Using interface ppp0
–> pppd: Phone
–> pppd: Phone
–> pppd: Phone
–> pppd: Phone
–> pppd: Phone
–> pppd: Phone
–> local IP address 10.162.132.126
–> pppd: Phone
–> remote IP address 10.64.64.64
–> pppd: Phone
–> primary DNS address 172.20.2.10
–> pppd: Phone
–> secondary DNS address 172.20.2.39
–> pppd: Phone
–> Script /etc/ppp/ip-up run successful
–> Default route Ok.

La connexion est établie.

Petite explication:

J’ai un réseau local en 192.168.160.0 et deux sous réseaux (192.168.210.0 et 192.168.220.0) dont une machine qui fait office de routeur avec 3 interfaces connectées sur les 3 réseaux.

Mon problème, quand je suis sur une machine du réseau local, je ne peux pas accéder aux machines des 2 sous-réseaux, donc il faut que je précise la route sur ma machine local, mais cela est simple si la route est toujours la même mais si prochainement j’ ajoute un nouveau sous réseau, il faut ajouter une nouvelle route donc la meilleure solution est d’installer un démon qui récupère tout seul la meilleure route à prendre pour accéder aux sous-réseaux.

Donc sous les conseils de Patrice Conil, j’installe « Bird » sur la machine routeur (qui va faire un broadcast sur le réseau pour distribuer les routes vers les sous-réseaux) et sur la machine locale (qui va écouter sur le réseau pour récupérer les routes vers les sous-réseaux).

Coté machine routeur (Debian4) :

# apt-get install bird

Dans /etc/bird.conf

protocol kernel {
persist;                # Don’t remove routes on BIRD shutdown
scan time 20;           # Scan kernel routing table every 20 seconds
export all;             # Default is export none

}

protocol device {
scan time 10;           # Scan interfaces every 10 seconds
}

protocol direct {
export all;
}

protocol rip {
export all;
import all;
port 1520;
authentication plaintext;
password « text »;
honor always;
interface « eth* »{ mode broadcast; };
}
Démarrer le service:

# /etc/init.d/bird start

Coté machine locale (Ubuntu 8.04) :

# sudo apt-get install bird

Je veux récupérer toutes les routes sauf la route pour mon réseau local (192.168.160.0), car elle passe par un autre routeur.

# sudo gedit /etc/bird.conf

log « /var/log/bird.log » all;

debug protocols all;
protocol kernel{
learn;
import all;
export all;
}

protocol device{
}

protocol rip {
import filter {
if net ~ [ 192.168.160.0/24 ] then {   # Only remote networks
reject;
}
else accept;
};
#    export all;
port 1520;
authentication plaintext;
password « text »;
honor neighbor;
interface « eth* »{mode broadcast;};
}

On démarre le service Bird et on fait un tail sur le fichier log de bird et au bout de 30s, et on voit

qu’il écoute bien sur le réseau et qu’il récupère bien les routes.

# sudo /etc/init.d/bird start

# tail -f /var/log/bird.log

10-02-2009 18:28:34 <TRACE> rip1: Listening on eth0, port 1520, mode broadcast (192.168.160.255)
10-02-2009 18:28:42 <TRACE> rip1: Broadcasting routing table to eth0
10-02-2009 18:28:44 <TRACE> device1: Scanning interfaces
10-02-2009 18:28:49 <TRACE> rip1: Broadcasting routing table to eth0
10-02-2009 18:28:51 <TRACE> rip1: block: 192.168.160.61 tells me: 192.168.160.0/24 available, metric 1…
10-02-2009 18:28:51 <TRACE> rip1 > added [best] 192.168.160.0/24 via 192.168.160.61 on eth0
10-02-2009 18:28:51 <TRACE> kernel1 < added 192.168.160.0/24 via 192.168.160.61 on eth0
10-02-2009 18:28:51 <TRACE> rip1 < forced accept by protocol 192.168.160.0/24 via 192.168.160.61 on eth0
10-02-2009 18:28:51 <TRACE> rip1 < added 192.168.160.0/24 via 192.168.160.61 on eth0
10-02-2009 18:28:51 <TRACE> rip1: block: 192.168.160.61 tells me: 192.168.210.0/24 available, metric 1…
10-02-2009 18:28:51 <TRACE> rip1 > added [best] 192.168.210.0/24 via 192.168.160.61 on eth0
10-02-2009 18:28:51 <TRACE> kernel1 < added 192.168.210.0/24 via 192.168.160.61 on eth0
5)

10-02-2009 18:28:51 <WARN> Netlink: No such process
10-02-2009 18:28:51 <TRACE> rip1 < forced accept by protocol 192.168.210.0/24 via 192.168.160.61 on eth0
10-02-2009 18:28:51 <TRACE> rip1 < added 192.168.210.0/24 via 192.168.160.61 on eth0
10-02-2009 18:28:51 <TRACE> rip1: block: 192.168.160.61 tells me: 192.168.220.0/24 available, metric 1…
10-02-2009 18:28:51 <TRACE> rip1 > added [best] 192.168.220.0/24 via 192.168.160.61 on eth0
10-02-2009 18:28:51 <TRACE> kernel1 < added 192.168.220.0/24 via 192.168.160.61 on eth0
10-02-2009 18:28:51 <WARN> Netlink: No such process
10-02-2009 18:28:51 <TRACE> rip1 < forced accept by protocol 192.168.220.0/24 via 192.168.160.61 on eth0
10-02-2009 18:28:51 <TRACE> rip1 < added 192.168.220.0/24 via 192.168.160.61 on eth0

Puis pour vérifier nous tapons la commande route:

# sudo route

192.168.220.0    192.168.160.61    255.255.255.0   UG    0      0        0 eth0
192.168.160.0     *               255.255.255.0   U     0      0        0 eth0
192.168.110.0    192.168.160.61    255.255.255.0   UG    0      0        0 eth0
link-local      *               255.255.0.0     U     1000   0        0 eth0
default         router-ebm 0.0.0.0         UG    0      0        0 eth0

Merci encore à Patrice Conil pour son aide.

J’espère que cet article pourra aider quelques personnes.

On s’aperçoit via la console de Virtual Center que dans l’onglet Configuration/Storage Adapters de l’ESX Server que les LUNs sont détecter mais
que le SAN nous autorise pas à se connecter (car on récupère bien les paths, l’ID du SAN, mais pas sa capacité).

Au démarrage du serveur nous voyons le message :
—————————————————————————
VMWARE: Device that would have been attached as scsi disk sdg at scsi0, channel 0, id 1, lun 6
Has not been attached because it is a duplicate path or on a passive path
——————————————————————————

En se rendant sur l’outil de management de Navisphere, on ne trouve pas notre ESX Server, tout ça est normal car on doit installer sur l’ESX l’agent Navisphere
qui va nous permettre de déclarer notre Server sur le SAN.

En épluchant différentes docs de ESX Server, il est indiqué qu’il n’est pas souhaitable d’installer des paquets RedHat sur ESX, donc je pensais que l’outil NaviAgent de RedHat n’était pas
compatible,mais après plusieurs tentatives malheureuses , j’ai quand même voulu essayer NaviAgent de RedHat sur ESX et là, dès l’installation terminée nous avons vu apparaître le Server ESX dans l’outil du management du SAN et nous l’avons ajouté dans le LUN souhaité.

Maintenant, il est possible grâce à l’onglet Configuration/Storage/Add Storage d’ajouter le LUN et de le formater en VMFS.

Pour commencer, il faut s’enregistrer sur le site de VMware pour générer des numéros de série.

Installation sur Debian Etch:

J’ai découvert un petit utilitaire très intéressant qui permet de réparer très simplement le boot Grub,

ça nous est arrivé à tous de ne plus pouvoir booter sur notre système Linux.

Rendez-vous sur ce site qui propose un utilitaire qui s’appelle Super Grub Disk.

Envy ici et le paquet module-assistant

Ces deux paquets installés, j’exécute le logiciel en mode console (Ctrl+Alt+F1) et je stoppe le serverX

# sudo /etc/init.d/gdm stop

# sudo envy -t

Désinstaller l’ancien driver, (si déjà une version installée) et aprés installer le driver et répondre « Yes » aux questions posés à la fin de l’installation.

Démarrer le server X

# startx

Dans Applications/Outils systéme un icone NVIDIA est présent, cela va nous permettre de gérer la résolution et surtout de manager les sorties écrans quand on ajoutera un Video Projecteur.