[moresk24]

ça sèche ? o)


Bon j'ai un autre soucis.. mais je vais ouvrir un autre Topic... parce que là ça cause de tout o)

Merci en tout cas pour votre aide.

Moresk

[moresk24]

et bien...

en utilisant toujours webmin

création d'utilisateurs dans 'système' pour chacun des sites
puis des serveurs virtuels dans apache
et l'accès FTp est venu tout seul ma fois...

[BBR]

comment as-tu installé tes domaines ?

[moresk24]

j'enchaine : je me connecte en FTP sur le Kim, cela veut il dire qu'il y a automatiquement un serveur FTP qui tourne sur le serveur ?

[moresk24]

bon G trouvé (et avant de lire la réponse de BBR promis juré ;-) )

Dans Mysql -> Autorisations des utilisateurs, j'ai mis logiquement la permission LOCK TABLES à mon utilisateur 'mega3d', et zou le script ne sort plus d'erreur

;-)

[BBR]

le reste il te dit clairement que mega3d n'a pas le droit d'utiliser la base mega, faut que tu regardes de ce côté là
soit tu t'es trompé dans le nom du user soit dans celui de la base

[moresk24]

ça doit se toucher le -pPassword

là, t'as choisi la question la plus facile avoue o)

[BBR]

ça doit se toucher le -pPassword

[moresk24]

entre voir de quoi ça parle, comprendre et apprendre (c'est à dire refaire)... y'a de la marge o)

Allez, je vous en pose une petite : mysqldump

deux sites
l'un à une sauvegarde auto depuis deux ans qui tourne sans problème
pour l'autre je recopie le fichier .sh du premier, je change ce qu'il faut (-u -p, nom de la base)
je lance.. mais :
mysqldump: Got error: 1044: Access denied for user 'mega3d'@'localhost' to database 'mega' when using LOCK TABLES

J'ai cherché sur le web pour pas vous tomber dessus de suite, mais pas trouvé..;
Vous en pensez quoi ?


question subsidiaire :
on peut se passer de mettre un espace entre -p et le password dans la commande mysqldump ?
du genre -> mysqldump -u mega3d -pMonMotDePass mega > mega3d_mysql_dump_$CUR_DATE.sql

Voilà pour cette fin d'aprem o)

[BBR]

Je crois que tu vas avoir appris en une semaine plus qu'en 3 ans
Ce n'est que le début

[moresk24]

En effet...

Merci o)

[nowwhat]

et à quoi correspondent ces fichiers là : other_vhosts_access.log ?

Va voir ton /etc/apache2/conf.d
T'as un fichier "other-vhosts-access-log." ?
La réponse se trouve dans ce fichier.

[BBR]

https://wiki.apache.org/httpd/InternalDummyConnection
http://blog.nicolargo.com/2011/03/su...onnection.html
je suppose que c'est surtout des lignes avec : Apache (internal dummy connection)"

[moresk24]

et à quoi correspondent ces fichiers là : other_vhosts_access.log ?

[BBR]

Une fois que tu auras modifié tes fichiers, dans webmin, tu vas dans Système, Rotation de fichier journal et là tu cliques en bas sur Forcer la rotation du journal
Sur cette page tu peux aussi cliquer sur Modifier les options globales, ce sera peut-être plus simple pour toi et cela s'appliquera à tous les logs

[BBR]

les fichiers en .gz sont compressés et comme c'est du texte ils diminuent radicalement
vu la taille tu devrais changer la configuration des rotations
se déplacer dans le répertoire

cd /etc/logrotate.d

là tu vas voir tous les fichiers de configuration de rotation des logs
tu édites les fichiers et tu mets soit daily à la place de weekly ou tu peux aussi spécifier une taille maxi du fichier log, par exemple ici, c'est par défaut une fois par semaine mais si le fichier atteint 50M, la rotation se fait (le fichier log est compressé et un nouveau est ouvert)

/var/log/le_chemin_vers_les_logs_du_domaine_error_log {
    rotate 52
    weekly
        size 50M
    compress
    postrotate
    /usr/sbin/apache2ctl graceful ; sleep 5
    endscript
    sharedscripts
}

à adapter à ta configuration
et pour le fichier apache2

/var/log/apache2/*.log {
    weekly
size 50M
    missingok
    rotate 52
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        /etc/init.d/apache2 reload > /dev/null
    endscript
    prerotate
        if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
            run-parts /etc/logrotate.d/httpd-prerotate; \
        fi; \
    endscript
}

tu as juste à modifier les lignes en gras

[moresk24]

dans etc/con.d/
mon fichier awstats contient :

*/10 * * * * www-data [ -x /usr/share/awstats/tools/update.sh ] && /usr/share/awstats/tools/update.sh

# Generate static reports:
#10 03 * * * www-data [ -x /usr/share/awstats/tools/buildstatic.sh ] && /usr/share/awstats/tools/buildstatic.sh

[moresk24]

Dans var/log/apache2 je vois par exemple :
other_vhosts_access.log qui pèse 225MB -> ce matin à 7:15
other_vhosts_access.log.1 qui pèse 713 MB 6> 3 may
sinon les autres other_vhosts_access.log.10.gz par exemple ne pèse que 23MB
les autres fichiers du même nom pèse environ 20MB-24MB

les acces.log -> 101 kb et access.log.1 -> 344 kb
et les autres access.XX.log.gz -> moins de 20 kb


Lorsqu'on "kill" un processus, le fait de redémarrer le serveur relancera t il se processus ?
car depuis que j'ai kill hier celui concernant awstats, j'ai fait la Maj de debian 6 (avec anxiété mais succès lol) et rebooté le serveur mais ma page d'accès aux stats me renvoie désormais une erreur 404 (The requested URL / was not found on this server.)

Moresk

[buddy]

il n'a toujours pas fini à 7h du matin par exemple ?
beh alors c'est que ton serveur est trop limite en cpu par rapport aux logs qu'il y a ... ce n'est pas normal que çà prenne autant de temps.

Dans ton logrotate, apache est configuré comment ?
more /etc/logrotate.d/apache

si les logs sont trop gros, remplace
weekly par daily
et
si tu veux par exemple garder les logs apache des 365 derniers jours mets
rotate 365

tu as redémarré le serveur après les mises à jour ?si non, çà peut être utile de le faire ....
tape dans la console SSH
reboot

[moresk24]

le soucis c'est qu'il calcule sans s'arrêter, prenant au mini 85% du CPU...

[buddy]

heu, c'est la même chose...
# = ligne commentée donc non lu/appliquer

est-ce grave si ton CPU fait les calculs pour awstats ? ce n'est pas le pub recherché d'avoir des statistiques ?

sinon, tu peux le supprimer ici : /etc/cron.d/awstats mais du coup awstats ne marchera plus ...

[nicobilaine]

ça serait il si simple de passer d'une version à une autre ?

En théorie et avec Debian et ses dérivés : oui. Par contre, si il y a des modifications dans les fichiers de configuration ou si les paquets changent radicalement, il faut répondre à une question (garder l'ancien fichier de config, prendre le nouveau, comparer les deux, ...). Et comme on est connecté en SSH, il vaut mieux lancer la commande "screen" avant (ça permet, de ce que j'ai compris, de lancer une session virtuelle et de pouvoir la reprendre) car en cas de coupure de la liaison, il faut couper la mise à jour en cours et la relancer en espérant qu'il n'y ai pas de soucis.
Dans tous les cas, il faut une bonne sauvegarde.

[BBR]

quand tu mets un # devant une ligne tu la "commentes" c'est à dire que tu empêches sa prise en compte (c'est comme si elle n'existait pas)

edit : zut je n'avais pas vu les commentaires au-dessus

[moresk24]

Les commandes apt-* ne mettent pas à jour la version de debian (6, 7, 8) mais juste les paquets de la distribution actuelle. Pour changer de version, il faut modifier le fichier "/etc/apt/sources.list" avec le nom de la version suivante (donc "wheezy" au lieu de "squeeze") puis refaire les mises à jour. Bien entendu, il faut faire les sauvegardes avant au cas où.

ça serait il si simple de passer d'une version à une autre ?

Est-ce que #mysqldump est dans un script? Si oui, le # au début de l'instruction la met en commentaire, elle n'est donc pas exécutée.

En effet c'est une ligne d'un script
Merci pour la réponse

[nicobilaine]

Les commandes apt-* ne mettent pas à jour la version de debian (6, 7, 8) mais juste les paquets de la distribution actuelle. Pour changer de version, il faut modifier le fichier "/etc/apt/sources.list" avec le nom de la version suivante (donc "wheezy" au lieu de "squeeze") puis refaire les mises à jour. Bien entendu, il faut faire les sauvegardes avant au cas où.

Est-ce que #mysqldump est dans un script? Si oui, le # au début de l'instruction la met en commentaire, elle n'est donc pas exécutée.

[moresk24]

Une p'tite question en passant :
c koi la différence entre #mysqldump et mysqldump ?

Mais que ça ne vous détourne pas du problème de base : surcharge du cpu dû à un script d'awstats ;-)

[BBR]

apt-get install htop
puis pour le lancer : htop
c'est comme top mais en mieux

[moresk24]

bon, la Maj s'est bien déroulée, le serveur est toujours là en : (Debian Linux 6.0.10)

[moresk24]

Merci BBR, Buddy et Nowwhat pour ces informations

Nowwhat :
Ma connexion sat me permet en effet des DL et UpL en illimité de 23:00 à 7:00

J'ai fait les sauvegardes dont tu parles (/etc, /home, /root, /boot et tout le /etc depuis le travail. Donc ça c ok

les sites sont 'rangés' dans le répertoire /home/ et non dans le /var/www/ -> pas bien ?

Je n'ai pas de serveur mail d'installé sur le kim. C'était un projet, mais ne me sentant pas de taille, j'ai abandonné

je vais donc cette aprem me lancer dans la Maj de Debian 6, avant de me pencher sérieusement sur le passage du serveur vers Debian 7 (Wheezy, la dernière verion = 7.8).


Pour en revenir à mon soucis de base : surcharge du CPU :

je vous avais je crois raconté qu'une sauvegarde se faisait à l'heure ou cette surcharge semblait apparaitre.
j'ai donc désactivé cette tâche cron, mais... la surcharge à repris vers 00:20
Sur les conseil d'un gars comme vous : commande top pour voir la liste des processus en route
repérage d'un processus qui prend 86% du CPU
commande 'ps aux' pour en connaitre le PID
puis un 'kill'
Le processus en cause semble lancé par l'user www-data -> statistiques du site principal hébergé sur ce serveur (par AWStats)
C'est donc la semble t il que se situe le soucis de surcharge du CPU

Voilà où j'en suis.

Moresk

[nowwhat]

Sans le "-y" :

apt-get update && apt-get upgrade

Ceci est comparable avec la mise à jour de Windows:
La liste des programmes à mettre à jour jour est chargé (apt-get update) - ce qui est une opération sans risque.
La liste des programmes à mettre à jour est affiché (apt-get upgrade).
A toi de confirmer avec Y + entrée.

Fait comme ton OS Windows: accepte ces mise à jour de sécurité sans réfléchir. Certains services/programmes seront redémarré, et ça se passe bien dans 99,999 % des cas.

Mais attention: cette opération te ramène à la dernière version de Debian 6 (Squeeze). cette version n'est plus supporté par 'Debian' depuis des lustres.
La date de fin du support de Debian 7 (Wheezy) est aussi connu: "Debian 8" est sortie, ça fait plus d'une semaine.

Prépare-toi pour passer ton serveur vers Debian 7 (Wheezy, la dernière verion = 7.8), tu sera tranquille pour un bout de temps.
AVANT de procéder, il suffit de lire quelques des milliers des procédures disponible sur le net.
Que tu te fasse un idée ce qu'il faut faire.

Je te conseille de copier un max de données présent sur ton serveur vers ton PC.
Le répertoire et toutes les sous-répertoires:
/etc
/home
/root
/boot

Le répertoire /var/ est spécial. Je te conseille de copier
/var/www/* (surtout - normalement, tes sites sont là)
/var/log/*
et tout autre répertoire dans /var/ qui t’intéresse.

Ta connexion (satellite) ne te permet de transférer des données illimités entre minuit et 07h00 ?

edit: bonus: http://journaldunadminlinux.fr/aptic...-jours-debian/
Un petit outil très sympa.
Après install, edit /etc/apticron/apticron.conf pour que tu change EMAIL="....." pour ton adresse mail, exempel: EMAIL="ton-adressemail.tld".
Condition: je présume que t'as un serveur mail sur ton dédié.

[buddy]

salut,

sous debian apt-get update tout seul n'update rien ...

Il faut faire

apt-get update && apt-get upgrade -y

tu peux si tu veux reboot ton serveur après. (commande reboot). Il me semble que c'était recommandé pour corriger les failles de sécurité de fin 2014. (shellshock + les failles SSL)

apt-get update && apt-get upgrade -y && reboot

[BBR]

c'est le serveur qui se connecte, pas toi !
pour les sauvegardes tu as des pistes par ici : http://www.how-to.ovh/viewforum.php?f=9
une sauvegarde sur le serveur ne sert à rien si ton disque rend l'âme.

[moresk24]

Merci BBR,

dernière question avant que je ne me lance : est ce ma connexion internet qui est utilisée pour cette MAJ du serveur ?
A priori non, mais Je demande cela car je suis sur un Internet par satellite, avec donc un forfait limité en DL et UpL

La Maj est à faire une fois par semaine dis tu.... et une fois par '3 ans' ne suffit donc pas ?? o) Donc j'ai du retard, je vais le rattraper
Je me contenterai de la commande 'apt-get update' pour la première fois

La sauvegarde du site principale se fait sur le serveur, et je télécharge de temps en temps cette sauvegarde
ça serait quoi la solution la plus 'sérieuse' ?

J'ose pas... apt-get update... o)

[moresk24]

Merci BBR,

dernière question avant que je ne me lance : est ce ma connexion internet qui est utilisée pour cette MAJ du serveur ?
A priori non, mais Je demande cela car je suis sur un Internet par satellite, avec donc un forfait limité en DL et UpL

La Maj est à faire une fois par semaine dis tu.... et une fois pas '3 ans' ne suffit donc pas ?? o) Donc j'ai du retard, je vais le rattraper
Je me contenterai de la commande 'apt-get update' pour la première fois

La sauvegarde du site principale se fait sur le serveur, et je télécharge de temps en temps cette sauvegarde
ça serait quoi la solution la plus 'sérieuse' ?

J'ose pas... apt-get update... o)

[BBR]

Tu laisses faire, ça va se connecter sur le site de Debian et récupérer les mises à jour et les installer, rien d'autre.
C'est à faire au moins une fois par semaine.
As-tu aussi un système de sauvegarde externe au serveur ? (tu parles de sauvegardes mais elles se font où ? Si c'est sur le serveur elles ne servent à rien)
Perso je fais toujours
apt-get update && apt-get upgrade -y
afin que les paquets soient aussi upgradés si besoin mais sur une distribution pas mise à jour depuis des lustres, je ne sais pas si c'est judicieux

[moresk24]

Allez soyons fous !!
Mais...
Une fois la commande 'apt-get update' lancée, y aura t il d'autre chose à faire ?
Dois-je par exemple arrêter apache ou autre avant de lancer cette commande ?
En résumer : à quoi dois je m'attendre lorsque j'aurais appuyé sur 'return' ?

[pascaltits]

là ton os et peut être un peu vieux et surtout pas à jour du tout.
BBR à raison, ton serveur doit être bourré de failles qui ont peut être compromis ton serveur ...
Une réinstallation complète serai plus sure, et surtout retenir la leçon :
apt-get update de façon régulière.

[BBR]

Debian 6 s'arrête à la 6.0.10
la commande est simple, en ssh tu tapes cela et tout se mettra à jour :
apt-get update
et OUI il faut toujours faire les mises à jour car ton serveur doit être bourré de failles

et Debian en est à la Version 8, sans aller jusqu'à la 8, passer en Debian 7.8 serait déjà bien

[moresk24]

et pour la commande dmesg :

quelque chose en particulier ?
Parce que je ne peux pas l'ensemble du texte (trop long)

[moresk24]

Warning - Your system is actually running Debian Linux version 6.0.5.

Webmin version 1.740 is now available, but you are running version 1.610.

Je dois mettre à jour Debian ?
La chose se fera t elle simplement ?

[pascaltits]

En observant l'utilisation du CPU je m'aperçois que depuis le 23 avril les pic à 100 (% ) sont très nombreux.

A quel fréquence ? est-ce régulier ? quel heure ?

J'ai redémarré le serveur (qui a eu du mal d'ailleurs),

que donne :
dmesg

Pascal

[BBR]

ce serveur est-il à jour ?

[moresk24]

faut regarder les logs et éventuellement faire les tests hardware car le serveur pourrait ralentir à cause d'un I/O Wait important du a un HDD défaillant ou a un site devenu trop gros pour votre système de backup qui a besoin d'optimisation.

Quels logs dois je regarder ? parce que des fichiers log j'en vois partout o)

La sauvegarde quotidienne pèse 500 mega (+ 2 mega pour la sauvegarde de la BDD)

Vous n'avez pas des graphs de monitoring (autre que le manager bien sûr) ?

Des graphs... que je pourrais trouver où sur le serveur ?
A noter que n'étant pas professionnel de la profession, j'utilise Webmin...

Merci de votre aide Janus

[janus57]

Bonjour,

faut regarder les logs et éventuellement faire les tests hardware car le serveur pourrait ralentir à cause d'un I/O Wait important du a un HDD défaillant ou a un site devenu trop gros pour votre système de backup qui a besoin d'optimisation.

Vous n'avez pas des graphs de monitoring (autre que le manager bien sûr) ?

Cordialement, janus57

[moresk24]

Serveur :
Système (OS)
Debian 6.0 LTS ("Squeeze") (oldoldstable)
Boot
hd (Boot from hard drive (no netboot))
Nom commercial
Kimsufi 2G


Bonjour,

En observant l'utilisation du CPU je m'aperçois que depuis le 23 avril les pic à 100 (% ) sont très nombreux. J'ai redémarré le serveur (qui a eu du mal d'ailleurs), l'utilisation du cpu est alors retombée à ce qui était la norme précédemment (pas plus haut que 25), mais de nouveau, 24 heures plus tard,les pics à 100 sont redevenus très fréquents.

A noter qu'une sauvegarde du site hébergé sur ce serveur se lance vers minuit trente (tâche cron), et il me semble que le soucis de surcharge du CPU s'est redéclenché à cette heure là.
Ce site tourne depuis 3 ans, et la sauvegarde depuis ce temps n'a jamais posé de soucis....

Pouvez vous m'apporter une petite aide pour que je sache comment résoudre ce problème qui occasionne un ralentissement net sur le site principal que j'héberge sur ce serveur..

Merci pour votre aide.

Stève Cuvelier