- WAPT - lists.wapt.fr

Password Vnc
by Anicet GERMAIN 25 Jun '15

25 Jun '15

Bonjour, Je cherche à configurer le mot de passe du serveur du paquet VNC mais je ne trouve pas. Est-ce que quelqu'un pourrait m'aiguiller ? Merci -- *Anicet GERMAIN* Technicien systèmes et réseaux ------------------------------------------------------------------------ *ConceptHygiene.com * Informatique / Communication / Support ------------------------------------------------------------------------ TEL : *02 43 49 56 36* MAIL : agermain(a)concepthygiene.com <mailto:agermain@concepthygiene.com> WWW :

2 1

Re: [Wapt] Accès serveur apache souvent en rade
by claude juif 24 Jun '15

24 Jun '15

Le 24 juin 2015 04:27, LEMAIRE Philippe <lemaire.philippe(a)lfay.com.vn> a écrit : > Bonjour, > > Pour vous apporter de la matière voici l'intégralité de mes logs depuis > hier ... > > Hier après-midi Wapt fonctionnait bien et lorsque j'ai lancé ce matin vers > 9h la console => http/1.1 505 Service Unavailable. > Cela n'arrive pas tous les matins mais assez régulièrement quand même > (j'ai dû le faire hier matin également). > Un simple Service waptserveur restart suffit à tout remettre d'aplomb > > Je vous joint également 2 captures de HTop au cas où (avant que je fasse > Service waptserveur restart) > > Mon installation > VM, 2cpu, 8G Ram > Ubuntu 14.04 (serveur de base + openssh) > Dédié uniquement à Wapt 1.2.3.2 (installé il y a 15 jours) > > PS : Je n'avais pas fait la modif => local timeout=150 # 15 seconds loop. > J'essaye aujourd'hui ... > thunder lock: disabled (you can enable it with --thunder-lock) probably another instance of uWSGI is running on the same address ( 127.0.0.1:8080). bind(): Address already in use [core/socket.c line 763] Voici donc ce qu'il se passe. Sans doute après le logrotate, le service uwsgi n'est pas proprement tué. Il semblerait qu'un ou deux process soient toujours en cours, laissant le port 8080 ouvert, empechant ainsi de relancer uwsgi. Il faudrait ajouter une structure de controle vérifiant si des process uwsgi sont toujours en cours avant de relancer uwsgi. Cela peut se faire en traquant le fichier pid, Quelque chose comme : kill -15 `cat /var/run/waptserver.pid` avant de relancer uwsgi Je n'ai pas tout les détails de l'environnement, mais cela doit pouvoir se regler via logrotate. > > Merci pour votre aide > > Cordialement > Philippe Lemaire > > > > -----Message d'origine----- > De : WAPT [mailto:wapt-bounces@lists.tranquil.it] De la part de Denis > Cardon > Envoyé : mardi 23 juin 2015 17:31 > À : claude juif > Cc : wapt(a)lists.tranquil.it > Objet : Re: [Wapt] Accès serveur apache souvent en rade > > Bonjour Claude, > > (j'ai remis wapt(a)list.tranquil.it en copie) > > > Désinstallé le desktop pour éviter l'économie d'énergie ... Ca va un > > petit peu loin et l'economie d'energie ne fonctionne pas de cette facon. > > Jamais la gestion d'energie n'ira tuer vos processus pour ca. (Il mettra > > l'interface réseau en veille, peut etre, > > c'est le genre de comportement dont je parle... Dans l'agent wapt sur > les postes client Windows, on gère la mise en veille et les up/down > d'interfaces réseau car c'est pas du tout transparent pour un process > daemon comme waptagent.exe. > > Mais sur le serveur wapt, on a rien fait de spécial pour gérer cela car > on part du principe que l'on est en machine virtuelle. Donc si on a des > up/down sur les interfaces réseaux, un suspend to disk/ram, des sauts > dans le temps NTP ou d'autres bizarreries, je ne garantie pas que ça > fonctionne. > > De plus, sur un serveur Linux, la tradition est de ne pas installer > d'interface graphique... Un bon vieux ssh et ça fait l'affaire. > > > mais n'occasionnera jamais cette erreur : > > //...brutally killing workers.../ et /SIGINT/SIGQUIT received...killing > > workers.../ > > Uwsgi fait des messages qui peuvent sembler perturbant, mais c'est le > fonctionnement "normal", par exemple en lui envoyant un SIGQUIT (ce que > fait le script /etc/init.d/waptserver stop ligne 84) on obtient : > > Stopping waptserver: SIGINT/SIGQUIT received...killing workers... > killing the spooler with pid 23446 > ........spooler (pid: 23446) annihilated > worker 1 buried after 1 seconds > worker 2 buried after 1 seconds > worker 3 buried after 1 seconds > worker 4 buried after 1 seconds > worker 5 buried after 1 seconds > worker 6 buried after 1 seconds > worker 7 buried after 1 seconds > worker 8 buried after 1 seconds > worker 9 buried after 1 seconds > worker 10 buried after 1 seconds > worker 11 buried after 1 seconds > worker 12 buried after 1 seconds > worker 13 buried after 1 seconds > worker 14 buried after 1 seconds > worker 15 buried after 1 seconds > worker 16 buried after 1 seconds > goodbye to uWSGI. > .waptserver. > > Mais c'est vrai que le "brutally" n'apparait pas normalement... Il > faudrait que Joël nous dise si ce message est apparut après une relance > manuelle du serveur ou non. > > > /Ces 2 messages indiquent que le process uwsgi recoit un sigint ou > > sigquit ce qui arrive quand l'utilisateur presse Ctrl-C./ > > Le process uwsgi est lancé par défaut en mode daemon par le script > d'init, on ne doit pas pouvoir lui envoyer un ctrl-C (sauf si on le > lance à la main en mode débug)... > > > /Pour pouvoir débugguer ce problème il faudrait : / > > / > > / > > /Avoir les fichiers /var/log/messages et /var/log/syslog ainsi que > > /var/log/kern.log/ > > / > > / > > /Quelque chose kill UWSGI et il faudrait savoir ce que c'est ;)/ > > en effet, il faudrait avoir plus d'information, mais pour commencer, je > veux être sûr qu'il n'y a pas d'autres choses qui interagissent avec les > processus serveur. Il y a plus de 300 serveurs WAPT déployés sous Linux > et Windows, et ce comportement nous a été remonté que deux fois sur la > mailing list. Je veux donc d'abord écarter les problèmes liés à la > machine spécifiquement. > > Cordialement, > > Denis Cardon > > > > > > > / > > / > > / > > / > > > > > > > > Le 23 juin 2015 10:57, Denis Cardon <denis.cardon(a)tranquil-it-systems.fr > > <mailto:denis.cardon@tranquil-it-systems.fr>> a écrit : > > > > Bonjour Joel, > > > > Je me rend compte que j'ai oublié de répondre. > > > > Le temps du test, j'ai installé debian avec le bureau Gnome. Il > > est en > > effet probable que la gestion de l'énergie pose problème. Que > > doit je > > modifier pour corriger ce problème? > > > > > > Il serait intéressant déjà de désinstaller les paquets desktop. Il y > > a une page sur stackexchange [1] qui suggère la ligne de commande > > suivante: > > > > apt-get purge $(tasksel --task-packages desktop) > > > > Cordialement, > > > > Denis Cardon > > > > > > [1] > > > http://unix.stackexchange.com/questions/56316/can-i-uninstall-gui-from-debi… > > > > > > > > > > Cordialement, Latieule Joël - TICE / Collège Jules Ferry de > Narbonne > > > > Le 11/06/2015 15:23, Denis Cardon a écrit : > > > > Bonjour Joel, > > > > Oui j'ai simplement fait l'installation de Jessie et > > fait les mises à > > jour avant de faire l'installation de wapt. C'est > > vraiment étrange, ça > > ressemble à une mise en veille des services plus qu'à un > > plantage. > > > > > > petite question juste pour être sûr, est ce que > > l'installation jessie > > est minimaliste (ie un prompt texte sur un fond noir) ou > > bien il y a > > un environnement graphique complet et les outils d'économie > > d'énergie > > qui vont avec?... > > > > Pour faire l'installation serveur, le mieux c'est de faire > > l'installation en mode texte en décochant TOUTES les options > > sauf le > > serveur SSH que l'on conserve. Vu le matériel serveur, il ne > > devrait > > pas y avoir de mode économie d'énergie trop agressif sur les > > ports > > réseaux ou le reste du matériel, mais il vaut mieux ne rien > > installer > > d'inutile pour éviter que le serveur ne se comporte comme un > > desktop. > > > > Après, ce qui est encore préférable, c'est d'installer une > > couche de > > virtualisation (par exemple XenServer ou consort), et > > d'installer le > > serveur WAPT en machine virtuelle. > > > > Cordialement, > > > > Denis Cardon > > > > > > Je vais refaire l'installation d'ici peut si je n'arrive > > pas à trouver > > de solution mais j'aurai préféré trouver la cause. > > > > > > Cordialement, Latieule Joël - TICE / Collège Jules Ferry > > de Narbonne > > > > Le 10/06/2015 08:57, Yann DAVID a écrit : > > > > Le 09/06/2015 13:11, Latieule Joel a écrit : > > > > Si je repart sur une toute nouvelle installation > > de debian. Que > > doit je > > sauvegarder pour retrouver la liaison entre mes > > postes client et le > > serveur wapt ? > > > > > > Salut Joël, > > T'as rien fait d'autre que de dédier ta Debian à > wapt ? > > > > Sinon, j'ai justement refait une install de wapt sur > > Jessie y'a à > > peine 48 heures (wapt tournait sous Win2003 jusque > là). > > > > Comme l'a dit Hubert, j'ai recopié mes paquets > > (logiciels et host). > > La seule chose à ne pas faire pour éviter de > > recommencer à zéro, c'est > > de régénérer la paire de clés. > > Pour ma part, j'ai pas copié mongodb, les machines > > sont en train de > > remonter toutes seules petit à petit. > > > > Pour le moment ça roule. > > > > Cordialement, Latieule Joël - TICE / Collège > > Jules Ferry de Narbonne > > > > Le 02/06/2015 09:07, Latieule Joel a écrit : > > > > Le redémarrage du service wapt permet de > > rétablir son fonctionnement > > mais je n'ai pas trouver la commander pour > > lister les processus. En > > pièce jointe vous trouverez la réponse > > complète de dmesg > > > > > > Les commandes pour l'espaces disque et ram > > montre qu'il reste de la > > marge > > > > root@srv-omv:/home/administrateur# df -h > > /Sys. de fichiers Taille Utilisé Dispo Uti% > > Monté sur > > /dev/sda1 46G 7,3G 37G 17% / > > udev 10M 0 10M 0% > /dev > > tmpfs 1,6G 8,8M 1,6G 1% > /run > > tmpfs 3,9G 88K 3,9G 1% > > /dev/shm > > tmpfs 5,0M 0 5,0M 0% > > /run/lock > > tmpfs 3,9G 0 3,9G 0% > > /sys/fs/cgroup > > tmpfs 798M 20K 798M 1% > > /run/user/1000/ > > > > > > root@srv-omv:/home/administrateur# free -m > > / total used free > > shared buffers cached > > Mem: 7975 1354 6620 > > 11 76 496 > > -/+ buffers/cache: 782 7193 > > Swap: 16321 0 16321/ > > > > > > Pour le fichier /var/log/waptserver.log en > > effet il était incomplet : > > /*** Starting uWSGI 2.0.7-debian (64bit) on > > [Tue Jun 2 07:35:01 > > 2015] > > ***// > > //compiled with version: 4.9.1 on 25 October > > 2014 19:17:54// > > //os: Linux-3.16.0-4-amd64 #1 SMP Debian > > 3.16.7-ckt9-3~deb8u1 > > (2015-04-24)// > > //nodename: srv-omv// > > //machine: x86_64// > > //clock source: unix// > > //pcre jit disabled// > > //detected number of CPU cores: 4// > > //current working directory: /// > > //writing pidfile to > /var/run/waptserver.pid// > > //detected binary path: /usr/bin/uwsgi-core// > > //setgid() to 33// > > //setuid() to 118// > > //your processes number limit is 31835// > > //your memory page size is 4096 bytes// > > //detected max file descriptor number: 1024// > > //lock engine: pthread robust mutexes// > > //thunder lock: disabled (you can enable it > > with --thunder-lock)// > > //uwsgi socket 0 bound to TCP address > > 127.0.0.1:8080 <http://127.0.0.1:8080> fd > 3// > > //Python version: 2.7.9 (default, Mar 1 > > 2015, 13:01:26) [GCC > > 4.9.2]// > > //Python main interpreter initialized at > > 0x1cb06d0// > > //python threads support enabled// > > //your server socket listen backlog is > > limited to 100 connections// > > //your mercy for graceful operations on > > workers is 60 seconds// > > //mapped 1237056 bytes (1208 KB) for 16 > cores// > > //*** Operational MODE: preforking ***// > > //WSGI app 0 (mountpoint='') ready in 0 > > seconds on interpreter > > 0x1cb06d0 pid: 5068 (default app)// > > //*** uWSGI is running in multiple > > interpreter mode ***// > > //spawned uWSGI master process (pid: 5068)// > > //spawned uWSGI worker 1 (pid: 5090, cores: > 1)// > > //spawned uWSGI worker 2 (pid: 5091, cores: > 1)// > > //spawned uWSGI worker 3 (pid: 5092, cores: > 1)// > > //spawned uWSGI worker 4 (pid: 5093, cores: > 1)// > > //spawned uWSGI worker 5 (pid: 5094, cores: > 1)// > > //spawned uWSGI worker 6 (pid: 5095, cores: > 1)// > > //spawned uWSGI worker 7 (pid: 5096, cores: > 1)// > > //spawned uWSGI worker 8 (pid: 5097, cores: > 1)// > > //spawned uWSGI worker 9 (pid: 5098, cores: > 1)// > > //spawned uWSGI worker 10 (pid: 5099, cores: > > 1)// > > //spawned uWSGI worker 11 (pid: 5100, cores: > > 1)// > > //spawned uWSGI worker 12 (pid: 5101, cores: > > 1)// > > //spawned uWSGI worker 13 (pid: 5102, cores: > > 1)// > > //spawned uWSGI worker 14 (pid: 5103, cores: > > 1)// > > //spawned uWSGI worker 15 (pid: 5104, cores: > > 1)// > > //spawned uWSGI worker 16 (pid: 5105, cores: > > 1)// > > //...brutally killing workers.../ > > /*** Starting uWSGI 2.0.7-debian (64bit) on > > [Tue Jun 2 08:41:02 > > 2015] *** > > compiled with version: 4.9.1 on 25 October > > 2014 19:17:54 > > os: Linux-3.16.0-4-amd64 #1 SMP Debian > > 3.16.7-ckt9-3~deb8u1 > > (2015-04-24) > > nodename: srv-omv > > machine: x86_64 > > clock source: unix > > pcre jit disabled > > detected number of CPU cores: 4 > > current working directory: > /home/administrateur > > writing pidfile to /var/run/waptserver.pid > > detected binary path: /usr/bin/uwsgi-core > > setgid() to 33 > > setuid() to 118 > > your processes number limit is 31835 > > your memory page size is 4096 bytes > > detected max file descriptor number: 65536 > > lock engine: pthread robust mutexes > > thunder lock: disabled (you can enable it > > with --thunder-lock) > > uwsgi socket 0 bound to TCP address > > 127.0.0.1:8080 <http://127.0.0.1:8080> fd 3 > > Python version: 2.7.9 (default, Mar 1 2015, > > 13:01:26) [GCC 4.9.2] > > Python main interpreter initialized at > 0xe4de90 > > python threads support enabled > > your server socket listen backlog is limited > > to 100 connections > > your mercy for graceful operations on > > workers is 60 seconds > > mapped 1237056 bytes (1208 KB) for 16 cores > > *** Operational MODE: preforking *** > > WSGI app 0 (mountpoint='') ready in 0 > > seconds on interpreter 0xe4de90 > > pid: 5185 (default app) > > *** uWSGI is running in multiple interpreter > > mode *** > > spawned uWSGI master process (pid: 5185) > > spawned uWSGI worker 1 (pid: 5190, cores: 1) > > spawned uWSGI worker 2 (pid: 5191, cores: 1) > > spawned uWSGI worker 3 (pid: 5192, cores: 1) > > spawned uWSGI worker 4 (pid: 5193, cores: 1) > > spawned uWSGI worker 5 (pid: 5194, cores: 1) > > spawned uWSGI worker 6 (pid: 5195, cores: 1) > > spawned uWSGI worker 7 (pid: 5196, cores: 1) > > spawned uWSGI worker 8 (pid: 5197, cores: 1) > > spawned uWSGI worker 9 (pid: 5198, cores: 1) > > spawned uWSGI worker 10 (pid: 5199, cores: 1) > > spawned uWSGI worker 11 (pid: 5200, cores: 1) > > spawned uWSGI worker 12 (pid: 5201, cores: 1) > > spawned uWSGI worker 13 (pid: 5202, cores: 1) > > spawned uWSGI worker 14 (pid: 5203, cores: 1) > > spawned uWSGI worker 15 (pid: 5204, cores: 1) > > spawned uWSGI worker 16 (pid: 5205, cores: 1) > > invalid HTTP request size (max 4096)...skip > > [pid: 5204|app: 0|req: 1/1] 127.0.0.1 () {38 > > vars in 567 bytes} [Tue > > Jun 2 08:42:15 2015] GET / => generated > > 6888 bytes in 458 msecs > > (HTTP/1.1 200) 2 heade$ > > [pid: 5204|app: 0|req: 2/2] 127.0.0.1 () {44 > > vars in 765 bytes} [Tue > > Jun 2 08:42:15 2015] GET > > /static/themes/tranquilit/style.css => > > generated 8443 bytes i$ > > [pid: 5198|app: 0|req: 1/3] 127.0.0.1 () {44 > > vars in 811 bytes} [Tue > > Jun 2 08:42:15 2015] GET > > /static/themes/tranquilit/img/logo-tis.jpg > > => generated 0 byt$ > > [pid: 5204|app: 0|req: 3/4] 127.0.0.1 () {44 > > vars in 808 bytes} [Tue > > Jun 2 08:42:15 2015] GET > > /static/themes/tranquilit/img/contact.jpg => > > generated 0 byte$ > > [pid: 5193|app: 0|req: 1/5] 127.0.0.1 () {44 > > vars in 776 bytes} [Tue > > Jun 2 08:42:15 2015] GET > > /static/themes/tranquilit/css/screen.css => > > generated 12613 b$ > > [pid: 5198|app: 0|req: 2/6] 127.0.0.1 () {44 > > vars in 776 bytes} [Tue > > Jun 2 08:42:15 2015] GET > > /static/themes/tranquilit/css/buttons.css => > > generated 2104 b$ > > [pid: 5196|app: 0|req: 1/7] 127.0.0.1 () {44 > > vars in 800 bytes} [Tue > > Jun 2 08:42:16 2015] GET > > /static/themes/tranquilit/img/bgd.png => > > generated 0 bytes in$ > > SIGINT/SIGQUIT received...killing workers... > > worker 1 buried after 1 seconds > > worker 2 buried after 1 seconds > > worker 3 buried after 1 seconds > > worker 4 buried after 1 seconds > > worker 5 buried after 1 seconds > > worker 6 buried after 1 seconds > > worker 7 buried after 1 seconds > > worker 8 buried after 1 seconds > > worker 9 buried after 1 seconds > > worker 10 buried after 1 seconds > > worker 11 buried after 1 seconds > > worker 11 buried after 1 seconds > > worker 12 buried after 1 seconds > > worker 13 buried after 1 seconds > > worker 14 buried after 1 seconds > > worker 15 buried after 1 seconds > > worker 16 buried after 1 seconds > > goodbye to uWSGI. > > *** Starting uWSGI 2.0.7-debian (64bit) on > > [Tue Jun 2 08:45:21 > > 2015] *** > > compiled with version: 4.9.1 on 25 October > > 2014 19:17:54 > > os: Linux-3.16.0-4-amd64 #1 SMP Debian > > 3.16.7-ckt9-3~deb8u1 > > (2015-04-24) > > nodename: srv-omv > > machine: x86_64 > > clock source: unix > > pcre jit disabled > > detected number of CPU cores: 4 > > current working directory: > /home/administrateur > > writing pidfile to /var/run/waptserver.pid > > detected binary path: /usr/bin/uwsgi-core > > setgid() to 33 > > setuid() to 118 > > your processes number limit is 31835 > > your memory page size is 4096 bytes > > detected max file descriptor number: 65536 > > lock engine: pthread robust mutexes > > thunder lock: disabled (you can enable it > > with --thunder-lock) > > uwsgi socket 0 bound to TCP address > > 127.0.0.1:8080 <http://127.0.0.1:8080> fd 3 > > Python version: 2.7.9 (default, Mar 1 2015, > > 13:01:26) [GCC 4.9.2] > > Python main interpreter initialized at > 0x970e90 > > python threads support enabled > > your server socket listen backlog is limited > > to 100 connections > > your mercy for graceful operations on > > workers is 60 seconds > > mapped 1237056 bytes (1208 KB) for 16 cores > > *** Operational MODE: preforking *** > > WSGI app 0 (mountpoint='') ready in 0 > > seconds on interpreter 0x970e90 > > pid: 5291 (default app) > > *** uWSGI is running in multiple interpreter > > mode *** > > spawned uWSGI master process (pid: 5291) > > spawned uWSGI worker 1 (pid: 5296, cores: 1) > > spawned uWSGI worker 2 (pid: 5297, cores: 1) > > spawned uWSGI worker 3 (pid: 5298, cores: 1) > > spawned uWSGI worker 4 (pid: 5299, cores: 1) > > spawned uWSGI worker 5 (pid: 5300, cores: 1) > > spawned uWSGI worker 6 (pid: 5301, cores: 1) > > spawned uWSGI worker 7 (pid: 5302, cores: 1) > > spawned uWSGI worker 8 (pid: 5303, cores: 1) > > spawned uWSGI worker 9 (pid: 5304, cores: 1) > > spawned uWSGI worker 10 (pid: 5305, cores: 1) > > spawned uWSGI worker 11 (pid: 5306, cores: 1) > > spawned uWSGI worker 12 (pid: 5307, cores: 1) > > spawned uWSGI worker 13 (pid: 5308, cores: 1) > > spawned uWSGI worker 14 (pid: 5309, cores: 1) > > spawned uWSGI worker 15 (pid: 5310, cores: 1) > > spawned uWSGI worker 16 (pid: 5311, cores: 1) > > invalid HTTP request size (max 4096)...skip > > [pid: 5299|app: 0|req: 1/1] 127.0.0.1 () {38 > > vars in 512 bytes} [Tue > > Jun 2 08:50:00 2015] GET /Packages => > > generated 233 bytes in 4 msecs > > (HTTP/1.1 404) 2 $ > > [pid: 5299|app: 0|req: 2/2] 127.0.0.1 () {38 > > vars in 512 bytes} [Tue > > Jun 2 08:50:00 2015] GET /Packages => > > generated 233 bytes in 0 msecs > > (HTTP/1.1 404) 2 $ > > [pid: 5299|app: 0|req: 3/3] 127.0.0.1 () {38 > > vars in 497 bytes} [Tue > > Jun 2 08:50:00 2015] HEAD / => generated 0 > > bytes in 421 msecs > > (HTTP/1.1 200) 2 headers$ > > [pid: 5299|app: 0|req: 4/4] 127.0.0.1 () {38 > > vars in 497 bytes} [Tue > > Jun 2 08:50:03 2015] HEAD / => generated 0 > > bytes in 420 msecs > > (HTTP/1.1 200) 2 headers$ > > [pid: 5299|app: 0|req: 5/5] 127.0.0.1 () {44 > > vars in 617 bytes} [Tue > > Jun 2 08:50:03 2015] POST /update_host => > > generated 1240 bytes in 19 > > msecs (HTTP/1.1 2$ > > [pid: 5310|app: 0|req: 1/6] 127.0.0.1 () {38 > > vars in 511 bytes} [Tue > > Jun 2 08:50:17 2015] GET /Packages => > > generated 233 bytes in 4 msecs > > (HTTP/1.1 404) 2 $ > > [pid: 5310|app: 0|req: 2/7] 127.0.0.1 () {38 > > vars in 511 bytes} [Tue > > Jun 2 08:50:17 2015] GET /Packages => > > generated 233 bytes in 0 msecs > > (HTTP/1.1 404) 2 $ > > [pid: 5311|app: 0|req: 1/8] 127.0.0.1 () {38 > > vars in 496 bytes} [Tue > > Jun 2 08:50:18 2015] HEAD / => generated 0 > > bytes in 429 msecs > > (HTTP/1.1 200) 2 headers$ > > [pid: 5310|app: 0|req: 3/9] 127.0.0.1 () {38 > > vars in 496 bytes} [Tue > > Jun 2 08:50:18 2015] HEAD / => generated 0 > > bytes in 428 msecs > > (HTTP/1.1 200) 2 headers$ > > [pid: 5310|app: 0|req: 4/10] 127.0.0.1 () > > {44 vars in 616 bytes} [Tue > > Jun 2 08:50:19 2015] POST /update_host => > > generated 1249 bytes in 30 > > msecs (HTTP/1.1 $ > > [pid: 5310|app: 0|req: 5/11] 127.0.0.1 () > > {38 vars in 511 bytes} [Tue > > Jun 2 08:50:22 2015] GET /Packages => > > generated 233 bytes in 0 msecs > > (HTTP/1.1 404) 2$ > > [pid: 5310|app: 0|req: 6/12] 127.0.0.1 () > > {38 vars in 511 bytes} [Tue > > Jun 2 08:50:29 2015] GET /Packages => > > generated 233 bytes in 0 msecs > > (HTTP/1.1 404) 2$ > > [pid: 5309|app: 0|req: 1/13] 127.0.0.1 () > > {38 vars in 511 bytes} [Tue > > Jun 2 08:50:41 2015] GET /Packages => > > generated 233 bytes in 4 msecs > > (HTTP/1.1 404) 2$ > > [pid: 5299|app: 0|req: 6/14] 127.0.0.1 () > > {38 vars in 496 bytes} [Tue > > Jun 2 08:52:20 2015] HEAD / => generated 0 > > bytes in 388 msecs > > (HTTP/1.1 200) 2 header$ > > [pid: 5299|app: 0|req: 7/15] 127.0.0.1 () > > {38 vars in 496 bytes} [Tue > > Jun 2 08:52:20 2015] HEAD / => generated 0 > > bytes in 431 msecs > > (HTTP/1.1 200) 2 header$ > > [pid: 5299|app: 0|req: 8/16] 127.0.0.1 () > > {38 vars in 496 bytes} [Tue > > Jun 2 08:52:24 2015] HEAD / => generated 0 > > bytes in 413 msecs > > (HTTP/1.1 200) 2 header$ > > [pid: 5299|app: 0|req: 9/17] 127.0.0.1 () > > {44 vars in 616 bytes} [Tue > > Jun 2 08:52:25 2015] POST /update_host => > > generated 1264 bytes in 30 > > msecs (HTTP/1.1 $ > > [pid: 5311|app: 0|req: 2/18] 127.0.0.1 () > > {38 vars in 511 bytes} [Tue > > Jun 2 08:52:35 2015] GET /Packages => > > generated 233 bytes in 1 msecs > > (HTTP/1.1 404) 2$ > > [pid: 5311|app: 0|req: 3/19] 127.0.0.1 () > > {38 vars in 511 bytes} [Tue > > Jun 2 08:52:36 2015] GET /Packages => > > generated 233 bytes in 0 msecs > > (HTTP/1.1 404) 2$ > > [pid: 5311|app: 0|req: 4/20] 127.0.0.1 () > > {38 vars in 496 bytes} [Tue > > Jun 2 08:52:36 2015] HEAD / => generated 0 > > bytes in 426 msecs > > (HTTP/1.1 200) 2 header$ > > [pid: 5311|app: 0|req: 5/21] 127.0.0.1 () > > {38 vars in 496 bytes} [Tue > > Jun 2 08:52:36 2015] HEAD / => generated 0 > > bytes in 392 msecs > > (HTTP/1.1 200) 2 header$ > > [pid: 5311|app: 0|req: 6/22] 127.0.0.1 () > > {44 vars in 616 bytes} [Tue > > Jun 2 08:52:37 2015] POST /update_host => > > generated 1264 bytes in 27 > > msecs (HTTP/1.1 $/ > > > > Cordialement, Latieule Joël - TICE / Collège > > Jules Ferry de Narbonne > > Le 01/06/2015 17:28, Denis Cardon a écrit : > > > > Bonjour Joël, > > > > Je suis en train de tester Wapt sur > > un serveur tout neuf et à > > par le > > système et ses mise à jour, > > strictement aucuns services ou > > applications > > n'ont été ajouté (sauf Wapt). Voici > > quelques informations que je > > peut > > trouver : > > > > * Système : Debian 8.0 "Jessie" > > * RAM : 8 Go > > * Processeur : Intel Xeon / 3,8 > > Ghz quatre cœur > > * WAPT : 1.2.3 > > > > > > merci beaucoup pour ces détails. En > > effet, je pense que l'on peut > > écarter le problème lié à la RAM... On a > > déjà eu ce soucis qui avait > > été remonté sur la mailing list avec des > > serveurs à 256Mo de RAM, je > > voulais donc être sûr. Normalement ça > > devrait pouvoir tourner très > > bien sur une machine avec 1Go de RAM. > > > > Le développement se fait actuellement > > sur la version Debian Jessie, > > donc on teste régulièrement wapt sur > > cette version. Après c'est vrai > > que l'on a principalement des > > déploiements en production sous > > Wheezy, > > la Jessie étant sortie que très > récemment. > > > > Pour obtenir les autres > > informations, quelle commande ou quel > > fichiers > > doit je ouvrir ? > > > > > > Ici le détail du fichier > > */var/log/waptserver.log* > > > > > / > > > *** Starting uWSGI 2.0.7-debian > > (64bit) on [Mon Jun 1 07:35:03 > > 2015] *** > > > compiled with version: 4.9.1 on 25 > > October 2014 19:17:54 > > > os: Linux-3.16.0-4-amd64 #1 SMP > > Debian 3.16.7-ckt9-3~deb8u1 > > (2015-04-24) > > > nodename: srv-omv > > > machine: x86_64 > > > clock source: unix > > > pcre jit disabled > > > detected number of CPU cores: 4 > > > current working directory: / > > > writing pidfile to > > /var/run/waptserver.pid > > > detected binary path: > /usr/bin/uwsgi-core > > > setgid() to 33 > > > setuid() to 118 > > > your processes number limit is 31835 > > > your memory page size is 4096 bytes > > > detected max file descriptor number: > 1024 > > > lock engine: pthread robust mutexes > > > thunder lock: disabled (you can > > enable it with --thunder-lock) > > > uwsgi socket 0 bound to TCP address > > 127.0.0.1:8080 <http://127.0.0.1:8080> > fd 3/ > > > > le log ne nous dit rien d'intéressant à > > part que le serveur à bien > > démarré... Est ce qu'il n'y a pas > > d'autre choses après? Est ce qu'il > > ne va pas jusqu'à : > > ... > > spawned uWSGI worker 15 (pid: 13581, > > cores: 1) > > spawned uWSGI worker 16 (pid: 13582, > > cores: 1) > > [pid: 13582|app: 0|req: 1/1] 127.0.0.1 > > () {38 vars in 529 bytes} > > [Mon Jun 1 07:07:23 2015] GET /Packages > > => generated 233 bytes in > > 5342 msecs (HTTP/1.1 404) 2 headers in > > 72 bytes (1 switches on > > core 0) > > > > Est ce que vous pourriez vérifier dans > > ce fichier waptserver.log au > > moment du problème d'accès si il y a des > > stack trace avec des > > exceptions python? > > > > Quand vous avez à relancer le serveur, > > est ce que vous avez tous les > > processus présents : > > * 1 process /usr/bin/mongod --config > > /etc/mongodb.conf > > * 16 process /usr/bin/uwsgi-core -d > > /var/log/waptserver.log > > --pidfile > > /var/run/waptserver.pid --ini > > /opt/wapt/waptserver/waptserver.ini > > --uid wapt --gid www-data --plugin > > http,python > > > > Est ce que vous pourriez vérifier la > > mémoire au moment du problème : > > free -m > > > > Juste pour vérifier, est ce qu'il y a > > suffisamment d'espace disque > > (le mongodb a tendance à consommer > > plusieurs centaines de Mo > > d'espace > > disque)? > > df -h > > > > Lors du prochain problème, est ce que > > vous pourriez essayer de > > relancer d'abord le serveur wapt plutôt > > que de relancer toute la > > machine pour voir si ça résoud le > problème. > > /etc/init.d/waptserver restart > > > > Après vous pouvez vous reconnecter à > > l'adresse (il faudra > > éventuellement le relancer deux fois la > > requête http pour > > ré-initialiser le pool de connexion du > > ProxyPassReverse) > > http://10.111.15.2 > > > > Lors du blocage du serveur python, est > > ce que vous pourriez vérifier > > si il y a toujours des connexions en > > cours, par exemple : > > > > [root(a)srvwapt.tranq mongodb]# netstat > > -tapn | grep 8080 > > tcp 0 0 127.0.0.1:8080 > > <http://127.0.0.1:8080> > > 0.0.0.0:* LISTEN > > 5762/uwsgi-core > > tcp 0 0 127.0.0.1:8080 > > <http://127.0.0.1:8080> 127.0.0.1:39525 > > <http://127.0.0.1:39525> > > TIME_WAIT - > > tcp 1 0 127.0.0.1:39527 > > <http://127.0.0.1:39527> 127.0.0.1:8080 > > <http://127.0.0.1:8080> > > CLOSE_WAIT 13336/apache2 > > tcp 0 0 127.0.0.1:8080 > > <http://127.0.0.1:8080> 127.0.0.1:39526 > > <http://127.0.0.1:39526> > > TIME_WAIT - > > tcp 1 0 127.0.0.1:34114 > > <http://127.0.0.1:34114> 127.0.0.1:8080 > > <http://127.0.0.1:8080> > > CLOSE_WAIT 13337/apache2 > > tcp 1 0 127.0.0.1:39372 > > <http://127.0.0.1:39372> 127.0.0.1:8080 > > <http://127.0.0.1:8080> > > CLOSE_WAIT 13336/apache2 > > tcp 1 0 127.0.0.1:37259 > > <http://127.0.0.1:37259> 127.0.0.1:8080 > > <http://127.0.0.1:8080> > > CLOSE_WAIT 13337/apache2 > > tcp 1 0 127.0.0.1:37269 > > <http://127.0.0.1:37269> 127.0.0.1:8080 > > <http://127.0.0.1:8080> > > CLOSE_WAIT 13337/apache2 > > tcp 1 0 127.0.0.1:37227 > > <http://127.0.0.1:37227> 127.0.0.1:8080 > > <http://127.0.0.1:8080> > > CLOSE_WAIT 13336/apache2 > > tcp 1 0 127.0.0.1:33772 > > <http://127.0.0.1:33772> 127.0.0.1:8080 > > <http://127.0.0.1:8080> > > CLOSE_WAIT 13336/apache2 > > tcp 0 0 127.0.0.1:39207 > > <http://127.0.0.1:39207> 127.0.0.1:8080 > > <http://127.0.0.1:8080> > > CLOSE_WAIT 13336/apache2 > > tcp 0 0 127.0.0.1:39202 > > <http://127.0.0.1:39202> 127.0.0.1:8080 > > <http://127.0.0.1:8080> > > CLOSE_WAIT 13337/apache2 > > tcp 0 0 127.0.0.1:8080 > > <http://127.0.0.1:8080> 127.0.0.1:39527 > > <http://127.0.0.1:39527> > > FIN_WAIT2 - > > > > Pour voir si c'est un soucis avec le > > wrapper uwsgi, vous pouvez > > aussi > > essayer de lancer le serveur python sans > > uwsgi avec les commandes > > /etc/init.d/waptserver stop > > python > /opt/wapt/waptserver/waptserver.py > > > > Pour écarter des problèmes systèmes, est > > ce que vous pourriez > > vérifier avec la commande dmesg si il > > n'y aurai pas quelque chose > > d'intéressant de ce côté là? > > > > J'ai jeté un coup d'oeil au logrotate du > > serveur wapt (le process > > qui > > fait tourner les logs pour éviter qu'ils > > deviennent trop gros). Il > > lance un redémarrage après la rotation > > des log à 6h du matin. > > Donc si > > vous n'avez que ce que vous mentionner > > dans le fichier de log, c'est > > que c'est tout ce qu'il y avait après le > > restart du uwsgi par le > > logrotate... > > > > Cordialement, > > > > Denis Cardon > > > > > > > > > > > > > > > > Cordialement, Latieule Joël - TICE / > > Collège Jules Ferry de > > Narbonne > > > > Le 29/05/2015 17:13, Denis Cardon a > > écrit : > > > > Bonjour, > > > > Je constate que chaque matin > > mon serveur WAPT est en > > panne et je > > doit > > relancer la machine pour que > > tout refonctionne. J'ai > installé > > WAPT > > sur > > une débian et la console de > > gestion ou > > la page http du serveur ne > > répond plus. Voici l'erreur > > que je > > rencontre : > > > > > > Service Unavailable > > > > The server is temporarily > > unable to service your > > request due to > > maintenance downtime or > > capacity problems. Please > > try again > > later. > > > > > ------------------------------------------------------------------------ > > > > > > > > Apache/2.4.10 (Debian) > > Server at 10.111.15.2 Port 80 > > > > > > le message indique que le > > serveur Apache n'arrive pas à > > récupérer > > une > > réponse du serveur uwsgi-python. > > C'est un peu succinct pour > > diagnostiquer un problème... > > Histoire de ne pas avoir à jouer > à > > madame > > soleil, il faudrait avoir > > quelques informations > > complémentaires : > > > > combien de RAM avec vous sur > > cette machine? Est ce qu'il y a > > d'autres > > choses services qui tournent en > > parallèle? Est ce qu'il y a des > > oomkiller dans la sortie de > > dmesg? Est ce qu'il y a des > process > > uwsgi > > qui tourne encore quand le > > serveur ne répond plus? Est ce > que > > process > > mongodb est toujours là? Quelle > > est la version du serveur wapt > > installé? Est ce qu'il y a des > > messages pertinents dans le > > fichier de > > log /var/log/waptserver.log? etc. > > > > Cordialement, > > > > Denis Cardon > > > > > > > > > > > > > _______________________________________________ > > WAPT mailing list > > WAPT(a)lists.tranquil.it > > <mailto: > WAPT(a)lists.tranquil.it> > > > http://lists.tranquil.it/listinfo/wapt > > > > > > > > > > > > > > > > > _______________________________________________ > > WAPT mailing list > > WAPT(a)lists.tranquil.it > > <mailto:WAPT@lists.tranquil.it> > > http://lists.tranquil.it/listinfo/wapt > > > > > > > > > > _______________________________________________ > > WAPT mailing list > > WAPT(a)lists.tranquil.it > > <mailto:WAPT@lists.tranquil.it> > > http://lists.tranquil.it/listinfo/wapt > > > > > > > > > > _______________________________________________ > > WAPT mailing list > > WAPT(a)lists.tranquil.it <mailto:WAPT@lists.tranquil.it> > > http://lists.tranquil.it/listinfo/wapt > > > > > > > > > > -- > > Denis Cardon > > Tranquil IT Systems > > Les Espaces Jules Verne, bâtiment A > > 12 avenue Jules Verne > > 44230 Saint Sébastien sur Loire > > tel : +33 (0) 2.40.97.57.55 <tel:%2B33%20%280%29%202.40.97.57.55> > > http://www.tranquil-it-systems.fr > > > > _______________________________________________ > > WAPT mailing list > > WAPT(a)lists.tranquil.it <mailto:WAPT@lists.tranquil.it> > > http://lists.tranquil.it/listinfo/wapt > > > > > > -- > Denis Cardon > Tranquil IT Systems > Les Espaces Jules Verne, bâtiment A > 12 avenue Jules Verne > 44230 Saint Sébastien sur Loire > tel : +33 (0) 2.40.97.57.55 > http://www.tranquil-it-systems.fr > > > _______________________________________________ > WAPT mailing list > WAPT(a)lists.tranquil.it > http://lists.tranquil.it/listinfo/wapt >

1 0

Request-URI too large
by Simon Fonteneau 24 Jun '15

24 Jun '15

Bonjour Nous faisons notre grande migration d'été vers windows 7 Du coup je veux supprimer tous les pc de wapt . Lorsque que je sélectionne tout les pc de l'inventaire pour supprimer, cela me génère une erreur. Simon --

3 2

Mettre à jour le client WAPT et remonté DMI
by LEMAIRE Philippe 24 Jun '15

24 Jun '15

Bonjour, Je continue d'avancer dans mes test de Wapt :c) Deux petits problèmes encore : · Lorsque j'essaye de « Mettre à jour le client WAPT » visiblement il ne le trouve pas (erreur 404). J'ai vérifié sur le serveur et j'ai bien waptagent.exe dans Wapt sur mon serveur. Est-ce parce que je n'ai pas encore d'update ? · Certains ordinateurs remontent dans la partie Inventaire matériel la section DMI et d'autres non. Quel réglage sur les postes (identiques normalement) faut-il vérifier pour avoir la remonté des infos DMI ? Si quelqu'un à des idée, je suis preneur ... Cordialement Philippe Lemaire

2 1

Accès serveur apache souvent en rade
by Latieule Joel 23 Jun '15

23 Jun '15

Bonsoir, Je constate que chaque matin mon serveur WAPT est en panne et je doit relancer la machine pour que tout refonctionne. J'ai installé WAPT sur une débian et la console de gestion ou la page http du serveur ne répond plus. Voici l'erreur que je rencontre : Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. ------------------------------------------------------------------------ Apache/2.4.10 (Debian) Server at 10.111.15.2 Port 80

7 16

comparaison de version
by Simon Fonteneau 19 Jun '15

19 Jun '15

Bonjour Cela fait un petit moment que j'utilise ce genre de chose pour comparer les logiciel softname = 'logicielname' check_installed = installed_softwares(softname) # si cette liste globale n est pas vide, on check chaque logiciel if check_installed: # boucle pour chaque logiciel trouvée for uninstall in check_installed: if Version(uninstall['version']) == Version(control['version'].split('-',1)[0]): print(u'The software is already installed' ) return (0); Mais je doit faire une erreur Dans mon cas: La version a installer (dans le fichier control) : 6.7.9.2 La version du logiciel présente sur la machine : 6.7.9 Mon problème est qu'il semblerai que le == fonctionne alors que les deux valeur ne sont pas égale. (vérifier avec print) Une piste ? Simon --

3 5

Remonté du champ Description
by LEMAIRE Philippe 18 Jun '15

18 Jun '15

Bonjour, Nouvel utilisateur de Wapt et nouveau sur la liste... Un petit soucis me tracasse ... Sur mon installation les postes remontent bien leurs infos à l'exception de la Description et c'est ballot j'en aurait besoin. Pourtant dans mon AD les descriptions sont bien présentent... Est-ce propre à mon installation ou est-ce général ? Aujourd'hui petite bizarrerie, un et un seul, ordinateur (sur 50) a une Description :c) mais qui ne correspond pas à sa description dans l'AD :c/ Quel champ de l'AD est utilisé dans Wapt pour remplir le champ Description ? Wapt serveur 1.2.3.2 sur une Ubuntu dédiée Cordialement Philippe

4 4

Remonté du champ Description
by LEMAIRE Philippe 17 Jun '15

17 Jun '15

Bonjour, Nouvel utilisateur de Wapt et nouveau sur la liste... Un petit soucis me tracasse ... Sur mon installation les postes remontent bien leurs infos à l'exception de la Description et c'est ballot j'en aurait besoin. Pourtant dans mon AD les descriptions sont bien présentent... Est-ce propre à mon installation ou est-ce général ? Aujourd'hui petite bizarrerie, un et un seul, ordinateur (sur 50) a une Description :c) mais qui ne correspond pas à sa description dans l'AD :c/ Quel champ de l'AD est utilisé dans Wapt pour remplir le champ Description ? Cordialement Philippe Wapt serveur 1.2.3.2 sur une Ubuntu dédiée

1 0

wapt sur Scribe
by Christophe Laurent 12 Jun '15

12 Jun '15

Bonjour, rencontrant des problèmes d'utilisation de wapt avec un serveur Scribe (paquets qui ne s'installent pas), quelqu'un a-t-il réussi à faire "cohabiter" les deux ? Merci d'avance. Christophe

4 3

Création d'un paquet pour Solidworks
by COHELEACH David 04 Jun '15

04 Jun '15

Bonjour, Je cherche à créer un paquet pour le déploiement de Solidworks 2012 R2. J'arrive très bien manuellement mais j'ai des erreurs avec Wapt. L'installation du MSI s'exécute bien mais à un moment l'installation s'annule. Après de multiple recherche, je me suis aperçu que dans le fichier Wapt généré, il me manque les fichiers .pyc. D'après la doc, effectivement les fichiers .svn, .git*, .pyc .dbg et .src sont exclu du package. Comment contourner cette directive ? Merci d'avance de votre aide et bravo pour votre logiciel. David COHELEACH Administrateur Réseau & Système 02 40 80 82 00 [cid:image001.jpg@01D081CD.36B75E10]

1 0