Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[Résolu] Nom d'hôte et httpd

Valdes

Bonjour à tous.

Ayant récemment installé Fedora 18, je me suis rendu compte après l'installation que le nouvel Anaconda ne proposait plus de modifier le "localhost" durant le processus d'installation. Ma machine ayant donc le nom "localhost.localdomain", j'ai décidé de parcourir le Web pour trouver un moyen de modifier le nom d'hôte et de domaine (ce que je faisais avant via Anaconda durant l'installation).
J'ai donc modifié le fichier /etc/sysconfig/network pour y ajouter la ligne

HOSTNAME=valportable.machindomain

Après avoir redémarré, ma machine avait bien pris en compte les modifications et mon shell m'affichait bien [root@valportable ~] à la place de [root@localhost ~]. Le problème, c'est qu'Apache, que j'avais installé avant de modifier le nom d'hôte, n'a pas eu l'air de comprendre cette modification et ne voulait tout simplement plus démarrer. J'ai essayé de modifier le fichier /etc/httpd/conf/httpd.conf pour y ajouter la ligne

ServerName valportable.machindomain

mais rien n'y a fait, même en triturant cette ligne dans tous les sens. J'ai donc remis les paramètres par défaut pour que je puisse m'en servir.

Est-ce normal qu'Apache n'aie pas compris le changement de nom d'hôte ? Ou bien est-ce moi qui n'ai rien compris au changement de nom d'hôte ? Ça serait d'ailleurs bien possible : j'avoue ne pas comprendre pourquoi un hostname me retournait "valportable.machindomain" et un domainname me retournait "(none)" alors qu'ils auraient dû me retourner respectivement "valportable" et "machindomain"...

Bref, y aurait-il une âme charitable qui pourrait éclairer ma lanterne ?

Pour information, mon Apache ne me sert que sur mon PC perso (rien en production) pour du développement Web et j'utilise NetworkManager via Gnome.

remi

As-tu ajouté le nouveau nom dans le fichier /etc/hosts ?
Apache a besoin de pourvoir "résoudre" le nom (et l'IP)

pingou

Il y a la commande (hostname je crois) qui permet de le faire aussi

slyholborn

c'est avec hostnamectl

section 2.3.2.4 http://fedorapeople.org/groups/docs/release-notes/en-US/sect-Release_Notes-Changes_for_Sysadmin.html

didierg

slyholborn wrote:c'est avec hostnamectl

En root:

hostnamectl set-hostname nom.domaine --static

et pour vérifier

hostnamectl status
hostname
hostname -s
hostname -d
hostname -f

Refuznik

bah autant directement modifier ton fichier host comme on faisait avant et ton apache redémarrera sans t'insulter.

Valdes

Merci pour vos réponses !

Alors :

remi wrote:As-tu ajouté le nouveau nom dans le fichier /etc/hosts ?
Apache a besoin de pourvoir "résoudre" le nom (et l'IP)

Non. À vrai dire, je sais pas où l'ajouter dans ce fichier. Mais surtout, il me semblait que hostnamectl permettait de s'affranchir de ce "détail".

pingou wrote:Il y a la commande (hostname je crois) qui permet de le faire aussi

Oui, mais c'est pas permanent.

slyholborn wrote:c'est avec hostnamectl

section 2.3.2.4 http://fedorapeople.org/groups/docs/release-notes/en-US/sect-Release_Notes-Changes_for_Sysadmin.html

Alors j'avais fait ça (hostnamectl set-hostname valportable.machindomain), mais y'a 2 choses bizarres :
- mon shell m'affiche [root@valportablemachindomain ~] au lieu de [root@valportable ~]
- hostname me retourne "valportablemachindomain" et domainname me retourne "(none)"

didierg wrote:
slyholborn wrote:c'est avec hostnamectl
En root:

hostnamectl set-hostname nom.domaine --static

et pour vérifier

hostnamectl status
hostname
hostname -s
hostname -d
hostname -f

Alors en rajoutant le --static, mon shell est bon ([root@valportable ~]), j'ai un hostname qui ressemble à quelque chose (valportable.machindomain) mais domainname me retourne toujours "(none)". Est-ce bien normal ?

Refuznik wrote:bah autant directement modifier ton fichier host comme on faisait avant et ton apache redémarrera sans t'insulter.

Ai-je besoin de modifier /etc/hosts si je passe par hostnamectl ?...

Je vais voir ce que httpd me dit après utilisation de --static avec hostnamectl et reboot.

Edit : après reboot, même problème avec httpd. Je vais essayer de rajouter "valhost.machindomain" quelque part dans /etc/hosts .

Valdes

Bon ben après avoir ajouté "valportable valportable.machindomain" à la fin de la première ligne de mon /etc/hosts et reboot, tout marche.

Du coup, était-ce nécessaire de passer par hostnamectl ?

didierg

Valdes wrote:Alors j'avais fait ça (hostnamectl set-hostname valportable.machindomain), mais y'a 2 choses bizarres :
- mon shell m'affiche [root@valportablemachindomain ~] au lieu de [root@valportable ~]
- hostname me retourne "valportablemachindomain" et domainname me retourne "(none)".

man hostname

Si c'est le programme dnsdomainname qui est appelé, il affichera le nom
de domaine DNS. Vous ne pouvez pas changer le nom de domaine DNS avec
dnsdomainname (voir après).

C'est pour cela qu'il faut vérifier avec les commandes hostname -d et hostname -f

-d, --domain
Affiche le nom de domaine DNS. N'utilisez pas la commande
domainname pour récupérer le nom de domaine DNS parce qu'elle
affichera en fait le nom de domaine NIS et non pas le non DNS.

-f, --fqdn, --long
Affiche le nom complet FQDN (Fully Qualified Domain Name). Un
FQDN consite en un nom d'hôte court et un nom de domaine DNS.
Sauf si vous utilisez "bind" ou NIS pour la recherche des hôtes
vous pouvez changer le FQDN et le nom de domaine DNS (qui fait
partie du FQDN) dans le fichier /etc/hosts.

Quatre commandes:

hostname -d
hostname -f
domainname
dnsdomainname

Valdes

Ok, donc c'est bien ce que je pensais : je ne comprends rien :

[root@valportable ~]# hostname -d
[root@valportable ~]# hostname -f
localhost
[root@valportable ~]# hostname
valportable.machindomain
[root@valportable ~]# domainname 
(none)
[root@valportable ~]# dnsdomainname 
[root@valportable ~]#

Y'a des commandes qui ne retournent rien, et d'autres qui me retournent "localhost"...
Je suis perdu.

ben51

J'ai rencontré le même problème que toi.
Et du coup je me demande si c'est le comportement normale de hostnamectl

Il y a même un tiket sur le bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=896756

didierg

Connecté à une LiveBox et après avoir passé une commande

# hostnamectl set-hostname fc18-azerty.home --static

# hostnamectl
   Static hostname: fc18-azerty.home
   Pretty hostname: fc18-azerty
         Icon name: computer-desktop
           Chassis: desktop
        Machine ID: xxxxxxxxxxxx 
        Boot ID: xxxxxxxxxxx
  Operating System: Fedora 18 (Spherical Cow)
       CPE OS Name: cpe:/o:fedoraproject:fedora:18
            Kernel: Linux 3.7.5-201.fc18.x86_64
      Architecture: x86_64

# hostname
fc18-azerty.home

# hostname -d
home

# hostname -f
fc18-azerty.home

# domainname
(none)

# dnsdomainname
home

Valdes

didierg : moi, ça ne fait vraiment pas comme chez toi :-P

Je commence peut-être à comprendre : serait-ce possible que, étant donné que je suis dans une résidence et que je passe donc par ce réseau, je ne puisse pas modifier le nom de domaine ? Ça expliquerait pourquoi le nom de domaine ne change pas et que valportable.machindomain soit considéré comme le nom d'hôte un coup sur 2...

madko

Donne nous ce que tu as dans /etc/hosts et dans /etc/resolv.conf ça peut jouer. Maintenant le hostname complet (fqdn) est normalement dans /etc/hostname

Valdes

Alors :

[root@valportable ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4 valportable valportable.machindomain
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

[root@valportable ~]# cat /etc/resolv.conf 
# Generated by NetworkManager
domain uqac.ca
search uqac.ca
nameserver 132.212.11.9
nameserver 132.212.11.73
nameserver 192.168.1.1

[root@valportable ~]# cat /etc/hostname
valportable.machindomain

madko

Rajoute peut être ton hostname complet dans /etc/hosts. Ensuite ton /etc/resolv.conf montre bien que la conf de NetworkManager positionne un domain (dnsdomain) en uqac.ca. Tu peux surement configurer ça pour par prendre les info fournit par le dhcp. Mais je pense qu'avec juste le fichier /etc/hosts tu devrais t'en sortir (pour Apache en tout cas).

Valdes

madko wrote:Rajoute peut être ton hostname complet dans /etc/hosts.

Euh mais justement, c'est pas ce que j'ai déjà rajouté ?

madko wrote:Ensuite ton /etc/resolv.conf montre bien que la conf de NetworkManager positionne un domain (dnsdomain) en uqac.ca. Tu peux surement configurer ça pour par prendre les info fournit par le dhcp. Mais je pense qu'avec juste le fichier /etc/hosts tu devrais t'en sortir (pour Apache en tout cas).

Comme je disais dans un post précédent, mon Apache marche depuis que j'ai viré la conf que j'avais faite et que je suis passé par hostnamectl.
En fait, la seule chose que je ne comprends pas à présent, c'est le fonctionnement des hostname et domainname : vu ce que me dit mon resolv.conf, je ne peux pas modifier mon nom de domaine étant donné qu'il est imposé et que c'est "uqac.ca", c'est bien ça ? Et si oui, est-ce que ça explique le fait que ce qui est après le point dans "valportable.machindomain" n'est pas mis dans le nom de domaine (vu qu'à priori le seul possible est uqac.ca) lorsque je fais un "hostnamectl set-hostname valportable.machindomain --static" ?

didierg

Valdes wrote:
madko wrote:Rajoute peut être ton hostname complet dans /etc/hosts.
Euh mais justement, c'est pas ce que j'ai déjà rajouté ?

En complément de mon post précédent voici mon /etc/hosts qui est non modifié:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

et /etc/hostname qui contient le full qualified hostname

fc18-azerty.home

Je viens de faire le test, la commande

hostnamectl set-hostname nom.domaine --static

met à jour le fichier /etc/hostname

ben51

Valdes wrote:Alors :

[root@valportable ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4 valportable valportable.machindomain
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

[root@valportable ~]# cat /etc/resolv.conf 
# Generated by NetworkManager
domain uqac.ca
search uqac.ca
nameserver 132.212.11.9
nameserver 132.212.11.73
nameserver 192.168.1.1

[root@valportable ~]# cat /etc/hostname
valportable.machindomain

Pour que ça fonctionne chez moi j'ai fait ça dans host (appliqué à ton cas)

[root@valportable ~]# cat /etc/hosts
127.0.0.1   valportable valportable.machindomain
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

madko

Valdes, la commande hostnamectl définit le nom d'hôte de ta machine, et c'est stocké dans /etc/hostname. Au boot, systemd lit ce fichier pour définir la variable d'environnement HOSTNAME.

Ensuite vu que t'es en DHCP (je suppose très fortement), une conf DNS est poussée sur ta machine. Dont le domain et le search du resolv.conf qui peuvent tranformer tes requêtes de résolution en autres choses. Si ta machine veut résoudre valportable elle peut le completer avec le search (donc uqac.ca). Le domain indique la partie à droite du 1er . de ton nom d'hôte. Donc là ya un peu conflit. Mais t'es pas obligé de recevoir toute la conf via dhcp, tu peux configurer NetworkManager pour définir la partie DNS à la main, mettre le domain que tu veux, laisser peut être le search si tu veux acceder à tes machines sur uqac.ca en tapant leur nom court.

Ensuite pour que la commande hostname se comporte bien, elle repose sur le /etc/hosts. Donc essaye de coller en face de 127.0.0.1 par ex, ou de ton ip, ton nom long, comme l'indique ben51.

Le comportement normale, c'est donc d'avoir le FQDN dans $HOSTNAME, ce que renvoit aussi la commande hostname. D'avoir le nom court à avec le hostname -s (donc partie gauche avant le 1er . du fqdn), et le nom long (trouvé a priori dans /etc/hosts ou sinon après par requete dns construite avec les info dans le resolv.conf) avec hostname -d. hostnamectl sans option indique pas mal de chose aussi.

dnsdomain ne devrait pas être vide, c'est étrange par contre. Pour domainname me semble que c'est en rapport avec NIS donc ne pas en tenir compte ici.

Page suivante »