Il y a quelques choses que vous pourriez faire pour essayer de déterminer ce qui se passe sur votre système.
Vous pouvez vérifier sur quels ports votre serveur écoute pour avoir une idée de ce qui se trouve dessus. Une bonne commande à utiliser serait :
[root@server ~]# netstat -tulpn
Connexions Internet actives (serveurs uniquement)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Nom du programme
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1880/smbd
tcp 0 0 0.0.0.0:5666 0.0.0.0:* LISTEN 1911/nrpe
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1759/sshd
Comme vous pouvez le voir dans la sortie exemple ci-dessus, il vous présente la version du protocole (tcp ou udp), l'adresse sur laquelle il écoute, le port ouvert et le programme qui écoute.
Dans l'exemple tronqué ci-dessus (une machine serveur), vous pouvez voir que les ports tcp 139, 5666 et 22 sont en écoute. Ils correspondent respectivement à samba, nrpe (agent Nagios) et ssh, et cela est confirmé lorsque vous vérifiez le programme qui écoute sur ce port.
De plus, vous pouvez vérifier la liste des démons qui sont configurés pour démarrer au démarrage. Pour cela, exécutez : chkconfig --list | grep "3:on"
Exemple :
[root@server ~]# chkconfig --list | grep "3:on"
NetworkManager 0:off 1:off 2:on 3:on 4:on 5:on 6:off
acpid 0:off 1:off 2:on 3:on 4:on 5:on 6:off
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
sysstat 0:off 1:on 2:on 3:on 4:on 5:on 6:off
udev-post 0:off 1:on 2:on 3:on 4:on 5:on 6:off
vncserver 0:off 1:off 2:on 3:on 4:on 5:on 6:off
webmin 0:off 1:off 2:on 3:on 4:off 5:on 6:off
x2gocleansessions 0:off 1:off 2:on 3:on 4:on 5:on 6:off
.
.
.
ou :
service --status-all
7 votes
La liste des processus, les écouteurs réseau (peut-être comparer à ce qui aurait dû être en cours d'exécution en se basant sur les scripts d'initialisation) ...
0 votes
"handed" comme accordé? (pour votre propre usage?) - Si c'est le cas, effacez et réinstallez à neuf, utilisez comme vous le souhaitez, est-ce important ce qu'ils ont fait?
1 votes
"handed" tel que donné pour soutien :|
5 votes
Putain! surement quelqu'un sait ce qu'ils sont pour? donc ils veulent que vous les souteniez mais ne savent pas ce qu'ils font ?!
2 votes
Incroyablement, cela arrive bel et bien. J'ai déjà été dans cette situation.
3 votes
Cela arrive vraiment. Je suis deux semaines dans le processus de découverte dans un environnement non documenté et orphelin. Mais la différence, c'est que je sais ce qu'il faut chercher... À l'auteur du post, comment vous êtes-vous retrouvé dans cette situation ? Nous pouvons répondre de manière générale, mais il doit y avoir quelqu'un qui en sait plus sur la configuration.
0 votes
La première face avant pourrait être un équilibreur de charge qui dirige le trafic vers les deux autres en fonction de leur charge.
11 votes
Éteignez-les. Quelqu'un vous dira, presque immédiatement, ce qui ne fonctionne pas.
3 votes
Comme l'a dit jscott - également, dans l'état éteint, ils continuent à effectuer toutes les tâches documentées :)
58 votes
NE L'ÉTEIGNEZ PAS. Débranchez le câble Ethernet, si vous souhaitez effectuer un test de cri. Si vous n'avez jamais vu un boîtier avec une durée de fonctionnement de deux ans échouer au redémarrage, cela arrivera à un moment donné. Ce n'est pas le moment d'ajouter cette frustration à la situation.
1 votes
@AaronCopley Des paroles très sages. J'ai moi-même été confronté à cette situation. Et pour information : Je ne les ai pas éteints. J'ai reçu 8 de ces choses dans une caisse d'expédition. Plusieurs disques ont échoué, 3 alimentations électriques. Et 2 n'ont pas pu récupérer complètement un raid corrompu : Ils avaient visiblement juste arraché les cordons d'alimentation et les piles de secours de ces caches de contrôleur raid étaient depuis longtemps mortes.
7 votes
Ce que tout le monde a dit, mais également : exécutez nmap contre eux.
0 votes
Pour répondre à la question de la manière dont j'ai obtenu cela : il s'agit d'un nouveau contrat de support qui a été transféré. L'ancien contrat était moins formel et nécessitait très peu de documentation. Certaines informations remontent à 5 ans, donc même si l'ancienne entreprise voulait nous aider, les techniciens qui ont mis en place les serveurs sont partis depuis longtemps.
2 votes
Utilisez un sniffer de paquets local (par exemple
wireshark
) pour observer comment les trois interagissent les uns avec les autres et avec le monde. Vous pouvez enregistrer pendant un certain temps, filtrer l'enregistrement de diverses manières, corroborer les numéros de port, etc. -- le tableau complet sera là si vous savez comment l'interpréter.0 votes
Question liée concernant un serveur Windows 2003. Les réponses les plus votées ne sont pas spécifiques à un système d'exploitation.
0 votes
@la suggestion de @goldilocks est bonne - si vous ne pouvez pas tcpdump/Wireshark directement, peut-être pouvez-vous mirroirer les ports du commutateur pour les serveurs et enregistrer le trafic sur une poste de travail sans interférer avec celui-ci.
0 votes
Je suis d'accord avec ce que Katherine a dit à propos d'exécuter nmap dessus (depuis une machine distante). Cela est utile pour vous donner une "inventaire" de tout port ouvert qui pourrait potentiellement être utilisé activement (fournissant ainsi des indices utiles sur sa fonction), mais qui ne sont pas nécessairement toujours significatifs. Dans certains cas, vous pouvez même vous connecter en telnet à différents ports juste pour voir si vous obtenez une réponse ou s'ils écoutent les connexions entrantes. Également utile si vous avez un accès direct au serveur, utilisez netstat -an
0 votes
Pendant que cette question est extrêmement large et excessive, elle ne l'est pas en même temps. Beaucoup d'entre nous avons été confrontés à ce même défi, et même si nos solutions spécifiques varieront grandement, le fait est que de nombreux nouveaux professionnels ne savent tout simplement pas par où commencer. Cette question semble proposer un bon point de départ pour n'importe qui, même pour des professionnels très expérimentés. Une liste de contrôle serait géniale !