Ubuntu-fr

Salut,

@jmoisy dans un bus iSCSI (SAN de façon général) les LUN sont détectées de façon asymétriques. En théorie chacune des LUN possède un ID (0, 1, 2...) qui en spécifie l'ordre, mais il semble que linux ne l'utilise pas. L'UUID ou le LABEL sont donc les seuls identifiants pour spécifier reconnaître les disques systématiquement.
De plus l'ordre de détection semble être lié au temps de réponse de celle-ci, les appellations de type sda/sdb dépendent de l'ordre de détéction. Pour des disques locaux (SATA,SAS,) le branchement sur le contrôleur défini de façon statique l'ordre dans le bus. Sur un SAN le bus est dynamique d’où l'utilisation les UUID ou les LABELS.
Note que la configuration du comportement des chemins d'un SAN dépend du constructeur et du modèle. Les P2000G3 sont des baies active/active qui présentent toutes les LUN en même temps sur tous les ports de tous les controleurs. Il est donc possible d'utiliser un algo de load-balancing de type RoundRobin sur les différents chemins.
C'est en général le daemon multipathd qui s'en charge sous linux, il pourrait être interressant que tu jettes un cou p d'oeil aux configurations possible.

@fifidji Les P2000G3 peuvent avoir plein de connectiques différentes SAS/iSCSI/FC voir même en combo de plusieurs. De façon générale quand le iSCSI est supporté tu trouveras au moins deux ports RJ45 dédiés au iSCSI par contrôleurs pour un combo, ou quatre ports RJ45 (ou 2 ports fibre 10G) dédiés pour du iSCSI only.

My two cents

@+
Elder

Salut,

Bon, en fait c'est théoriquement possible dans la mesure ou KVM supporte la virtualisation imbriquée (nested virtualisation).
Si les options de virtualisations sont correctement remontées dans la VM c'est jouable. Les perfs seront... franchement moyennes mais c'est possible.
La difficulté sera de faire passer le réseaux vers ta VM.
Pour ça il va falloir que tu joues avec ton firewall.
Le réseau par défaut de KVM est un réseau "bridgé" utilisant déjà le firewall de l'hôte :

root@myhost:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             192.168.122.0/24     ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootpc

Le truc maintenant serait que lorsque tu essaye de joindre un port sur ton ip publique, ce soit l'adresse de la VM qui réponde.
Alors je te conseil vivement de ne pas faire ça avec ton port 22 sinon tu ne pourras plus joindre ton vps en ssh. Tu peux éventuellement faire un truc comme ça pour le port 80.

iptables -t nat -I PREROUTING -p tcp -d IP_PUBLIQUE --dport 80 -j DNAT --to-destination IP_VM:80
iptables -I FORWARD -m state -d IP_VM/24 --state NEW,RELATED,ESTABLISHED -j ACCEPT

Ca devrait le faire...

@+
Elder

Salut,

Je suis d'accord avec ikoula, il va falloir regarder du côté du hardware.
Il n'y a rien de significatif dans les logs ce qui tend à montrer que les arrêts ne sont pas liés au système.
Les problèmatiques RAM peuvent être très aléatoires je commencerai par faire tourner un memtest et s'il ne remonte rien, vérifier ton alimentation, etc...

@+
Elder

Salut,

Vu d'ici tu n'as pas d'interface physique dans ton bridge donc ton trafic réseau n'est pas envoyé sur ton LAN.
Peux-tu envoyer un ifconfig -a et dire si tu utilise NetworkManager ou ifupdown ?

@+
Elder

Bon reprenons,
D'abord il faut s'assurer de la méthode d'activation du réseau.
Par défaut Ubuntu utilise NetworkManager la "nouvelle méthode" qui peut entrer en conflit avec la méthode "traditionnelle" ifupdown lorsque les deux sont utilisées en même temps.
Pour vérifier tu peux faire :
(Attention les relevés de config viennent de 2 machines différente, celle ci-dessous vient de mon laptop sous Ubuntu avec NetworkManager les suivantes de mon pc sous Debian avec ifupdown)

# systemctl status NetworkManager
● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
   Active: active (running) since mar. 2016-07-19 23:38:48 CEST; 3 days ago
 Main PID: 877 (NetworkManager)
   CGroup: /system.slice/NetworkManager.service
           ├─ 877 /usr/sbin/NetworkManager --no-daemon
           ├─1271 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /var/run/dhclient-br0.pid -lf /var/lib/NetworkManager/dhclient-78a6eebe-6c43-477e-8709-c57c8fa74920-br0.lease
           └─1412 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid --listen-address=127.0.1.1 --cache-size=0 --proxy-

juil. 23 07:27:14 mld-lap dhclient[1271]: DHCPACK of 192.168.1.58 from 192.168.1.1
juil. 23 07:27:14 mld-lap NetworkManager[877]: <info>  [1469251634.8192]   address 192.168.1.58
juil. 23 07:27:14 mld-lap NetworkManager[877]: <info>  [1469251634.8193]   plen 24 (255.255.255.0)
juil. 23 07:27:14 mld-lap NetworkManager[877]: <info>  [1469251634.8193]   gateway 192.168.1.1
juil. 23 07:27:14 mld-lap NetworkManager[877]: <info>  [1469251634.8193]   server identifier 192.168.1.1
juil. 23 07:27:14 mld-lap NetworkManager[877]: <info>  [1469251634.8193]   lease time 86400
juil. 23 07:27:14 mld-lap NetworkManager[877]: <info>  [1469251634.8193]   hostname 'mld-lap'
juil. 23 07:27:14 mld-lap NetworkManager[877]: <info>  [1469251634.8193]   nameserver '192.168.1.1'
juil. 23 07:27:14 mld-lap NetworkManager[877]: <info>  [1469251634.8193] dhcp4 (br0): state changed bound -> bound
juil. 23 07:27:14 mld-lap dhclient[1271]: bound to 192.168.1.58 -- renewal in 37471 seconds.

La il n'y a pas de doute, ça tourne.
De là deux possibilité :
- Tu fais ton bridge via NetworkManager
- Tu désactives NetworkManager et tu effectues ta config avec ifupdown (ce que tu as fait jusque là).

Pour une config avec ifupdown le fichier /etc/network/interfaces se paramètre au minimum tel que :

# The loopback network interface
auto lo br0
iface lo inet loopback

# The primary network interface
allow-hotplug eth1
iface eth1 inet manual

iface br0 inet static
        pre-up ifconfig eth1 up
        pre-up brctl addbr br0
        pre-up brctl addif br0 eth1
        address 192.168.1.100
        broadcast 192.168.1.255
        netmask 255.255.255.0
        gateway 192.168.1.1

Attention cette config est sur une Debian 8.5 et dans sa construction est un poil archaïque mais les lignes de pre-up permettent de s'assurer que :
- eth1 est up
- créer le bridge
- ajouter l'interface au bridge
(j'ajoute directement les dns dans /etc/resolv.conf mais tu peux continuer à utiliser resolvconf en plaçant les lignes dns-nameservers et dns-search local dans les paramètres de br0)

A partir de là l'adresse IP de ta machine physique (ton hôte dans la suite) est attribuée à br0 et ton interface physique n'est plus que le connecteur vers l’extérieur ce qui nous donne :

br0       Link encap:Ethernet  HWaddr 00:15:17:25:ac:6c  
          inet adr:192.168.1.100  Bcast:192.168.1.255  Masque:255.255.255.0
          adr inet6: fe80::215:17ff:fe25:ac6c/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1274 errors:0 dropped:0 overruns:0 frame:0
          TX packets:850 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0 
          RX bytes:243332 (237.6 KiB)  TX bytes:155967 (152.3 KiB)
[...]
eth1      Link encap:Ethernet  HWaddr 00:15:17:25:ac:6c  
          adr inet6: fe80::215:17ff:fe25:ac6c/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2523 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2505 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:499641 (487.9 KiB)  TX bytes:983668 (960.6 KiB)
          Interruption:47 Mémoire:fd3a0000-fd3c0000 
[...]
root@deb-wrk:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.00151725ac6c       no              eth1
[...]
root@deb-wrk:~# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 br0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
[...]

Tu remarques que l'adresse MAC (HWaddr) de br0 et de eth1 sont identiques, en fait br0 a hérité de l'adresse MAC de eth1

Ton hôte doit maintenant avoir un accès normal au réseau.
De la il faut paramétrer ta VM (en l’éteignant au préalable, pas obligatoire mais mieux) pour qu'elle utilise br0.
Tu peux le faire via l'interface graphique ou via virsh.
Une fois démarré tu devrais voir l'interface de ta VM (vnet0) dans br0

root@deb-wrk:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.00151725ac6c       no              eth1
                                                        vnet0

Et normalement là c'est bon.

@+

Salut,

Ton clavier n'est pas en QWERTY sur l'écran d'accueil ?
Depuis que j'ai changé le miens c'est le cas. Il revient en AZERTY une fois la session ouverte.
my two cents

@+
Elder

et de fait quand on appel directement http://69.70.69.203 on tombe sur la page par défaut d'apache.
Mais le nom perfectlife.com correspond à l'adresse 206.192.23.80.
Donc tu ne pourras pas ateindre 69.70.69.203 en utilisant le nom perfectlife.com avant d'avoir fait une modification DNS.

@+
Elder

Salut,

De base le problème de route serait sur la machine pour laquelle ça ne marche pas...
Tu peux poster les tables de routage du dom0 et du desktop et un brctl show de ton dom0 ?

@+
David

Salut,

Salut de mon point du vue tu as bien installé ton DNS mais tu as oublié de permettre les requétes.
Sur ma Debian ça ce passe dans /etc/bind/named.conf.options.
C'est la directive allow-query qui dit qui peut faire des demandes au serveur.

options {
        directory "/var/cache/bind";

        allow-query {
                any;
        };

        allow-recursion {
                any;
        };

        forwarders {
                8.8.8.8;
                8.8.4.4;
                //192.168.1.1;
        };

        tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab";
        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Bon, évidement mon DNS ne fonctionne que sur mon réseau local donc pas de risque a laisser les directives d'accès en open-bar (any). Lorsque le serveur sera en ligne sur internet il faudra limiter.

@+
Elder

PS:

ufw allow 53 

ouvre le port DNS (53) en tcp et udp

Salut,
Il est possible lors de l'installation de faire ton plan de partitionnement directement en LVM. Jette un oeil par là.
Personnellement j'ai tendance à conserver le dossier par défaut (/var/www) pour les sites web dans la mesure ou ça permet de faciliter l'administration si tu devais passer la main à quelqu'un d'autre.

@+
Elder

Salut,

Je ne suis pas fan de vbox mais il semble que la conversion directe ne fonctionne pas.
J'ai trouvé ce tuto en anglais avec, peut être, des pistes pour trouver des solutions.

@+
Elder

Salut,

Vu les codes de retour 400 (requête mal formée), 408 (timeout), 403 (interdit) les requêtes en question n'aboutissent pas.
Quand une requête arrive access.log l'enregistre, mais ça ne veut pas dire que la requête passe.

@+
Elder

Salut,

Je ne saisis pas l'obligation d'activer l'utilisateur root !
Le principe, depuis le début, sous Ubuntu est que root est désactivé et que l'utilisateur créé pendant l'installation peut exécuter toutes les commandes d'administration en les préfixant par sudo.
En tous cas tu ne devrais pas avoir à activer root, encore moins sur une machine destinée à héberger un service visible de l'extérieur comme un serveur web !
Si tu as un problème d'upload de fichier il te faudra jouer avec les droits en ajoutant, par exemple, ton utilisateur dans le groupe auquel appartient le dossier dans lequel tu veux uploader et en donnant des droits d'écriture au groupe sur le dossier (chmod g+rw mondossier).

Ce n'est pas parce que ton précédent serveurs était configuré avec deux pieds très sales qu'il faut le refaire !

@+
Elder