moresk24
29/05/2015, 17h39
merci BBR ;-)
merci beaucoup même ! ;-)
merci beaucoup même ! ;-)
www-data
BBR
29/05/2015, 13h32
je peux aussi te prêter le mien le temps que tu fasses ta migration (c'est un ks2 avec un ssd de 40 G) si ça te convient tu me dis, je le réinstalle en debian 8 puis je te file l'accès
janus57
29/05/2015, 13h06
Bonjour,
@moresk24 :
Voici l'état de ton serveur niveau HDD :
En supposant que toute les données sont utile (pas de nettoyage à faire), tu doit prévoir un serveur "tampon" de +/- 11Go pour ton /home les 3Go restant doivent être les BDD+logs+config logiciel, donc si on ajoute les BDD avec une marge prévoir 12/13Go.
Du coup y a d'autre prestataire que OVH (peu cher mais malheureusement pas encore testé), qui propose des VPS à petit prix pour ce genre d'opération.
Si tu veux des liens/nom je te le fait par mail car sur les forum KS/OVH je ne poste pas de liens d'autre hébergeur (du moins le moins possible).
Cordialement, janus57
@moresk24 :
Voici l'état de ton serveur niveau HDD :
Code:
root@moresk24:~# df -h Sys. fich. Taille Util. Dispo Uti% Monté sur rootfs 10G 3,0G 6,6G 31% / /dev/root 10G 3,0G 6,6G 31% / tmpfs 197M 272K 197M 1% /run tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 10M 0 10M 0% /dev tmpfs 393M 0 393M 0% /run/shm /dev/sda2 921G 11G 865G 2% /home
Du coup y a d'autre prestataire que OVH (peu cher mais malheureusement pas encore testé), qui propose des VPS à petit prix pour ce genre d'opération.
Si tu veux des liens/nom je te le fait par mail car sur les forum KS/OVH je ne poste pas de liens d'autre hébergeur (du moins le moins possible).
Cordialement, janus57
BBR
29/05/2015, 12h55
tout dépend de ton volume de données, tu as ceci http://www.ovh.com/fr/vps/vps-classic.xml création immédiate et pas de frais d'install
moresk24
29/05/2015, 12h40
y'aurait il moyen de louer un bout de serveur quelque part le temps de réinstaller le kim'vabien ?
serait ce une bonne idée ?
serait ce une bonne idée ?
janus57
28/05/2015, 10h23
Envoyé par moresk24
rien à voir, je pense tout simplement que suPHP (du moins la config) a sauté avec le migration et je suis prêt à parier qu'il a été installé par dessus Webmin car j'ai vu aucune option suPHP dans le panel webmin.
Du coup là tout les script PHP tourne en www-data (va sur le site qui est à l'user 'aquilib' et va sur la page test.php au même niveau que la page d'indexe, tu verra que sa tourne en www-data).
Donc là 2 choix :
- re-faire la config propre de suPHP (downtime à prévoir - "peu" important)
- réinstaller le tout (downtime à prévoir - important)
Pourquoi ces 2 choix "seulement" ?
Car visiblement ce serveur a été un peu trop touché à la main vis à vis du panel webmin (simple supposition, mais vu les différents problème ça doit pas être faux...), du coup re-partir sur un Debian 7 fraichement installé (avec le kernel Debian tant qu'a faire) puis par dessus soit virtualmin (plus complet de webmin pour le coup), soit un autre (genre vesraCP/ispconfig ou autre), mais là continuer ainsi c'est "chaud" car il faut se souvenirs de tout ce qui a été touché manuellement, ce qui doit en partie expliquer les problèmes suite à cette migration (en plus de ne pas avoir fait attention lors de la migration).
Cordialement, janus57
moresk24
28/05/2015, 10h01
il se peut que la section umask ne soit pas définie ?
je ne trouve pas les fichiers comme :
/etc/login.dfs ou /etc/bashrc.
je ne trouve pas les fichiers comme :
/etc/login.dfs ou /etc/bashrc.
janus57
26/05/2015, 20h04
Bonjour,
surtout que après vérification le script est executé en tant qu'utilisateur "sauvegardes" qui appartient au groupe "users", donc tout les fichiers avec un chmod qui autorise seulement le propriétaire vont te retourner des erreurs avec un script de backup exécuté par un simple user.
De plus si pour une raison X ou Y une personne arrive à accéder à ces script (surement exécuté par un cron) il pourrait très bien modifier le script pour envoyer le tout sur son serveur, en root il faudrait pirater le compte root et si lui se fait pirater en général on a pas le choix de formater le serveur et repartir sur une base saine.
Bref comme dit faut pas se casser la tête avec 1script de backup par site quand un script à lui tout seule peu le faire pour l'ensemble des sites et en incrémental en prime (gain de temps/vitesse/ressources).
Cordialement, janus57
surtout que après vérification le script est executé en tant qu'utilisateur "sauvegardes" qui appartient au groupe "users", donc tout les fichiers avec un chmod qui autorise seulement le propriétaire vont te retourner des erreurs avec un script de backup exécuté par un simple user.
De plus si pour une raison X ou Y une personne arrive à accéder à ces script (surement exécuté par un cron) il pourrait très bien modifier le script pour envoyer le tout sur son serveur, en root il faudrait pirater le compte root et si lui se fait pirater en général on a pas le choix de formater le serveur et repartir sur une base saine.
Bref comme dit faut pas se casser la tête avec 1script de backup par site quand un script à lui tout seule peu le faire pour l'ensemble des sites et en incrémental en prime (gain de temps/vitesse/ressources).
Cordialement, janus57
BBR
26/05/2015, 19h34
c'est pas tricher, juste être efficace, si t'as 2 domaines et un serveur, ta méthode peut encore être faisable, mais quand tu as plusieurs serveurs et des dizaines/centaines de domaines, c'est une perte de temps inutile
moresk24
26/05/2015, 19h01
Envoyé par BBR
janus57
26/05/2015, 19h00
Bonjour,
par faux, pourquoi s'amuser à faire tourner 3/4 scripts de backup en mode user alors qu'on peu le lancer en 1seule fois pour la totalité du serveur (backup-manager comme @BBR l'avait mis dans un autre post).
Sinon j'ai envoyé un mail et à première vu je dirais un problème de umask.
Cordialement, janus57
par faux, pourquoi s'amuser à faire tourner 3/4 scripts de backup en mode user alors qu'on peu le lancer en 1seule fois pour la totalité du serveur (backup-manager comme @BBR l'avait mis dans un autre post).
Sinon j'ai envoyé un mail et à première vu je dirais un problème de umask.
Cordialement, janus57
BBR
26/05/2015, 18h35
tu te compliques la vie, fais tes sauvegardes en root
moresk24
26/05/2015, 18h27
j'vais qd même pas faire un "chown -R user:users /home/user/www" avant chaque sauvegarde tout de même o)
moresk24
26/05/2015, 18h00
je remarque que ds le fichier /etc/apache2/httpd.conf
il n'y a que :
ServerName localhost
ne devrait il pas y avoir aussi :
LoadModule suphp_module /usr/lib/apache2/modules/mod_suphp.so
?
en fait c'est ds le fichier /etc/apache2/mods-available/suphp.load et il y a bien un lien symbolique ds /etc/apache2/mods-enabled/suphp.load
donc c pas là le soucis
il n'y a que :
ServerName localhost
ne devrait il pas y avoir aussi :
LoadModule suphp_module /usr/lib/apache2/modules/mod_suphp.so
?
en fait c'est ds le fichier /etc/apache2/mods-available/suphp.load et il y a bien un lien symbolique ds /etc/apache2/mods-enabled/suphp.load
donc c pas là le soucis
moresk24
26/05/2015, 17h21
et je devrais chercher plutôt où selon vous ?...
parce que ça cause des soucis dans mes backups cette appartenance à www-data
où alors je fais mes backups sous root et zou, mais c'est de la triche o)
sinon dans /etc/suphp/suphp.conf y'a :
[global]
;Path to logfile
logfile=/var/log/suphp/suphp.log
;Loglevel
loglevel=info
;User Apache is running as
webserver_user=www-data
;Path all scripts have to be in
docroot=/home:${HOME}/www
;Path to chroot() to before executing script
;chroot=/mychroot
; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false
;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=true
;Send minor error messages to browser
errors_to_browser=false
;PATH environment variable
env_path="/bin:/usr/bin"
;Umask to set, specify in octal notation
umask=0077
; Minimum UID
min_uid=100
; Minimum GID
min_gid=100
[handlers]
;Handler for php-scripts
application/x-httpd-suphp="php:/usr/bin/php-cgi"
;Handler for CGI-scripts
x-suphp-cgi="execute:!self"
parce que ça cause des soucis dans mes backups cette appartenance à www-data
où alors je fais mes backups sous root et zou, mais c'est de la triche o)
sinon dans /etc/suphp/suphp.conf y'a :
[global]
;Path to logfile
logfile=/var/log/suphp/suphp.log
;Loglevel
loglevel=info
;User Apache is running as
webserver_user=www-data
;Path all scripts have to be in
docroot=/home:${HOME}/www
;Path to chroot() to before executing script
;chroot=/mychroot
; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false
;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=true
;Send minor error messages to browser
errors_to_browser=false
;PATH environment variable
env_path="/bin:/usr/bin"
;Umask to set, specify in octal notation
umask=0077
; Minimum UID
min_uid=100
; Minimum GID
min_gid=100
[handlers]
;Handler for php-scripts
application/x-httpd-suphp="php:/usr/bin/php-cgi"
;Handler for CGI-scripts
x-suphp-cgi="execute:!self"
janus57
26/05/2015, 16h48
Bonjour,
surement que PHP est appelé via apache donc www-data, mais du coup avec suPHP normalement cela ne devrait pas être le cas (du moins si la config est bonne de bout en bout).
Cordialement, janus57
surement que PHP est appelé via apache donc www-data, mais du coup avec suPHP normalement cela ne devrait pas être le cas (du moins si la config est bonne de bout en bout).
Cordialement, janus57
BBR
26/05/2015, 16h14
parce qu'ils les ont envoyés par le web donc apache, peut-être ?
moresk24
26/05/2015, 16h05
bonjour les amis helpeurs
p'tite interrogation :
comment se fait il que certains de mes fichiers (notament des images .JPG déposés par des membres d'un des sites hébergés sur le serveur via un scipt phop de base) aient comme users et comme group 'www-data' ?
p'tite interrogation :
comment se fait il que certains de mes fichiers (notament des images .JPG déposés par des membres d'un des sites hébergés sur le serveur via un scipt phop de base) aient comme users et comme group 'www-data' ?