WAPT

wapt@lists.wapt.fr

1538 discussions

Logiciel Need-upgrade
by Florian FAVRE 08 Nov '16

08 Nov '16

Bonjour, Lors du déploiement de certaines applis, flash et chrome en particulier, l'install ne se fait pas. La tâche est terminée, mais le status de l'appli est en Need-Upgrade et le status de la machine est en Error. Savez-vous comment corriger ce problème ? Cordialement, Florian

2 1

Personnalisation acrobat reader dc à partir du msi
by Eric Sanders 07 Nov '16

07 Nov '16

Bonsoir, Je regarde le déploiement d'acrobat reader dc en version française. J'ai un soucis : Je personnalise le paquet depuis l'outils adobe et je créer un .msi. J'ai réussi à déployer ce paquet une fois. J'ai tenté une suppression sans problème. Lors d'une demande d'une nouvelle installation sur la même machine j'ai : [image: Images intégrées 1] setup.py (désolé pour la syntaxe je débute) : # -*- coding: utf-8 -*- from setuphelpers import * uninstallkey = ["{AC76BA86-7AD7-1036-7B44-AC0F074E4100}"] def install(): global uninstallkey global uninstallstring print('installing cg2a-adobeacrobatreaderdc-french') #install_msi_if_needed('AcroRead.msi') run(r'"AcroRead.msi" /q /norestart') Par avance, merci pour vos réponses,

3 3

Suppression de paquet depot wapt
by Eric Sanders 07 Nov '16

07 Nov '16

Bonsoir, Après avoir créer / déployé un paquet wapt d'après un msi. J'ai un soucis puisque celui-ci apparait avec une erreur d'interprétation de caractère : adobe-dc-français => adobe-dc-fran?ais J'aurais pus (avant deploement modifier le fichier control et le setup.py puis le dossier créer dans le dépot) mais maintenant c'est fait ... :-( Mon soucis donc c'est que je ne parvient plus a supprimer ce paquet du dépot ... Je me dit qu'éditer la bd en squilte me permettrait d'effacer l'enregistrement mais quid des implication d'une telle modification ? Existe t il un force pour supprimer un package de la console ? Par avance, Merci.

2 2

Suppression d'un paquet depot privée
by Eric Sanders 06 Nov '16

06 Nov '16

Bonsoir, J'ai créer un paquet acrobat reader à partir d'un msi extrait d'acrobat reader dc. L'exe à été télécharger depuis le site acrobat reader. Pour le télécharger, j'ai : - Selectionner l'os - Selectioner la version de l'os - selectionner la langue d'acrobat reader. Le soucis c'est qu'avant que j'ai fais une boulette :

1 1

Fwd: RE: [wаpt] télédіstrіbսtіоn аսtо...
by Olivier Pavilla 06 Nov '16

06 Nov '16

Merci aux modérateurs de faire ce qu'il est nécessaire de faire. S'inscrire à une ML avec un filtre anti-spam bête et méchant qui en retour pourri toutes les boites mails des abonnés à la liste. C'est moyen... -⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠ Message original -⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠ Objet: RE: [wаpt] télédіstrіbսtіоn аսtо... Date: 2016-⁠11-⁠06 07:01 De: "Christophe Garressus (Pibomulti S.A.)" < no-reply(a)spamenmoins.net > À: olivier.pavilla(a)u-psud.fr Répondre à: cgarressus(a)pibomulti.com < cgarressus(a)pibomulti.com > Bonjour, c'est CHRISTOPHE GARRESSUS (PIBOMULTI S.A.), Vous m’avez récemment envoyé un e-⁠mail, mais je n’ai pas pu le recevoir car je suis désormais protégé par un service anti-⁠spam (pour faire face aux nombreux courriers indésirables). Afin de débloquer votre mail, CLIQUEZ SUR LE LIEN CI-⁠DESSOUS ET RECOPIEZ SIMPLEMENT LE CODE d’authentification qui s’affichera : http://www.SpamEnMoins.com/Autoriser.php?E=b2xpdmllci5wYXZpbGxhQHUtcHN1ZC5m… [ 1 ] Je recevrai alors votre mail. Vous n’aurez ensuite plus besoin de faire cette action lors de vos prochains envois. Merci d'avance Christophe Garressus (Pibomulti S.A.) -⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠-⁠ Hello, this is CHRISTOPHE GARRESSUS (PIBOMULTI S.A.), To cope with ever increasing amounts of spam mail, we have subscribed to a filter service from SpamEnMoins.com. This service blocks all emails with the exception of trusted correspondents. So I have not yet received your last email, In order to prove you are a genuine sender and not a spam-⁠sending machine, PLEASE CLICK ON LINK BELOW AND FOLLOW THE INSTRUCTIONS on the page which opens. http://www.SpamEnMoins.com/Autoriser.php?E=b2xpdmllci5wYXZpbGxhQHUtcHN1ZC5m… [ 1 ] You will then be immediately and permanently added to my list of trusted correspondants. Your last email will also be delivered without delay. thank you Christophe Garressus (Pibomulti S.A.) Links: -⁠-⁠-⁠-⁠-⁠-⁠ [1] http://www.SpamEnMoins.com/Autoriser.php?E=b2xpdmllci5wYXZpbGxhQHUtcHN1ZC5m… -- Olivier Pavilla LIMSI -⁠ CNRS -⁠ Equipe AMIC Bât. 508 -⁠ Bur. 212 -⁠ Universite Paris Sud 91403 Orsay [48.707362 | 2.176182] Tel : 01 69 85 81 12 Message 1 sur 11

2 1

Télédistribution automatique.
by Olivier Pavilla 06 Nov '16

06 Nov '16

Bonjour Dans l'optique d'automatiser la télédistribution via WAPT sur mon parc machine. Je souhaiterai savoir si il est possible de télédistribuer automatiquement un un groupe de paquet lorsque la machine s'identifie à WAPT (pour la première fois). L'idée, c'est lorsqu'une machine se connecte au domaine, elle récupère l'agent wapt. J4aurais aimé que dans la foulé, le groupe de paquet commun a toutes les machines soit automatiquement descendu. J'explore mais je ne trouve pas de solution. -- Olivier Pavilla LIMSI - CNRS - Equipe AMIC Bât. 508 - Bur. 212 - Universite Paris Sud 91403 Orsay [48.707362 | 2.176182] Tel : 01 69 85 81 12

2 1

Fwd: RE: [wаpt] télédіstrіbսtіоn аսtо...
by pavilla 06 Nov '16

06 Nov '16

Merci aux modérateurs de faire ce qu'il est nécessaire de faire. S'inscrire à une ML avec un filtre anti-spam bête et méchant qui en retour pourri toutes les boites mails des abonnés à la liste. C'est moyen... -------- Message original -------- Objet: RE: [wаpt] télédіstrіbսtіоn аսtо... Date: 2016-11-06 07:01 De: "Christophe Garressus (Pibomulti S.A.)" <no-reply(a)spamenmoins.net> À: olivier.pavilla(a)u-psud.fr Répondre à: cgarressus(a)pibomulti.com <cgarressus(a)pibomulti.com> Bonjour, c'est CHRISTOPHE GARRESSUS (PIBOMULTI S.A.), Vous m’avez récemment envoyé un e-mail, mais je n’ai pas pu le recevoir car je suis désormais protégé par un service anti-spam (pour faire face aux nombreux courriers indésirables). Afin de débloquer votre mail, CLIQUEZ SUR LE LIEN CI-DESSOUS ET RECOPIEZ SIMPLEMENT LE CODE d’authentification qui s’affichera : http://www.SpamEnMoins.com/Autoriser.php?E=b2xpdmllci5wYXZpbGxhQHUtcHN1ZC5m… [1] Je recevrai alors votre mail. Vous n’aurez ensuite plus besoin de faire cette action lors de vos prochains envois. Merci d'avance Christophe Garressus (Pibomulti S.A.) ------------------------- Hello, this is CHRISTOPHE GARRESSUS (PIBOMULTI S.A.), To cope with ever increasing amounts of spam mail, we have subscribed to a filter service from SpamEnMoins.com. This service blocks all emails with the exception of trusted correspondents. So I have not yet received your last email, In order to prove you are a genuine sender and not a spam-sending machine, PLEASE CLICK ON LINK BELOW AND FOLLOW THE INSTRUCTIONS on the page which opens. http://www.SpamEnMoins.com/Autoriser.php?E=b2xpdmllci5wYXZpbGxhQHUtcHN1ZC5m… [1] You will then be immediately and permanently added to my list of trusted correspondants. Your last email will also be delivered without delay. thank you Christophe Garressus (Pibomulti S.A.) Links: ------ [1] http://www.SpamEnMoins.com/Autoriser.php?E=b2xpdmllci5wYXZpbGxhQHUtcHN1ZC5m… -- Olivier Pavilla LIMSI - CNRS - Equipe AMIC Bât. 508 - Bur. 212 - Universite Paris Sud 91403 Orsay [48.707362 | 2.176182] Tel : 01 69 85 81 12

1 0

[Announce] WAPT release 1.3.8
by Denis Cardon 04 Nov '16

04 Nov '16

============FRANÇAIS============ Bonjour à tous, L'équipe de Tranquil IT Systems a le plaisir de vous proposer la release WAPT 1.3.8. C'est une version mineure qui intègre un grand nombre d'améliorations techniques, sécuritaires et ergonomiques à Wapt, ainsi que deux correctifs de sécurité (cf. changelog ci-dessous). Désormais les distributions Redhat7 et CentOS7 sont également supportées par Wapt, avec SELinux activé. La procédure de mise à jour est décrite ici: https://dev.tranquil.it/scenari/guide_update/co/MAJ_infra_Wapt.html Si vous avez des questions lors de la mise à jour, vous pouvez trouver de l'aide sur le forum https://forum.tranquil.it/ ou sur la mailing liste https://lists.tranquil.it/listinfo/wapt Nous en profitons pour vous annoncer que Simon FONTENEAU du blog wapt.lesfourmisduweb.org a rejoint Tranquil IT Systems, notamment pour travailler sur WAPT et les prestations que nous pouvons vous proposer (formations, support, déploiement, etc.). Cordialement, L'équipe TIS ============ENGLISH============ Hello friends of WAPT The Tranquil IT Systems team is pleased to announce WAPT 1.3.8. It is a minor update that includes several technical improvements is security and ergonomy, as well as 2 security fixes (see changelog below). Now, Wapt works with RedHat7 and CentOS7 with SELinux enabled. Upgrade procedure can be found here (French only for the moment) https://dev.tranquil.it/scenari/guide_update/co/MAJ_infra_Wapt.html If you have questions during upgrade, you are welcome to use the forum https://forum.tranquil.it/ or the mailing list https://lists.tranquil.it/listinfo/wapt. It is mostly French but English speaker are welcome too. We take this opportunity to announce that Simon FONTENEAU from the wapt.lesfourmisduweb.org blog has joined the TIS team, to work on WAPT and the services the company can offer (training, support, deployment). Cheers. The Tranquil IT Systems team =Changelog= Security : * [SECURITY] Fix inheritance of rights on wapt root folder for Windows 10 during setup when installed in c:\wapt o On Windows 10, cacls.exe does not work and does not remove "Authenticated Users" from c:\wapt. cacls.exe has been replaced by icacls.exe. * On pre-wapt 1.3.7 systems, you can fix this by running the following command, or upgrade to wapt 1.3.8 (you may check http://dev.tranquil.it/wiki/WAPT_-_probl%C3%A8me_fr%C3%A9quent#Corriger_les…) : icacls.exe c:\wapt /inheritance:r This can be achieved with a GPO, or a wapt package * Note : in next versions of Wapt, the default install path of wapt will be changed from root folder c:\wapt to a more standard c:\ Program FIles\wapt. * By default, waptsetup.exe / waptsetup-tis.exe don't distribute certificates to avoid to deploy directly packages from Tranquil IT Systems. waptagent.exe by default distributes the certificates that are installed on the mangement desktop creating the waptagent. Core changes * The database structure has changed between 1.3.8 and 1.3.8.2 to includes additional attributes from packages : signer, signer_fingerprint, locale, and maturity. Signer and signer_fingerprint are populated when signing the package to identify the origin. This means local wapt database is upgraded when first starting wapt 1.3.8.2 and this is not backward compatible. * Installers have a limited set of options, the most common use of Wapt is priviledged. * [ADD] 3 new parameters for the waptexit policy behaviour : 'hiberboot_enabled','max_gpo_script_wait','pre_shutdown_timeout' recommended settings for waptexit / shutdown policy # hiberboot_enabled = 0 # max_gpo_script_wait = 180 # pre_shutdown_timeout = 180 These parameters are not set by default and should be added to wapt-get.inin [global] section if needed * [UPD] Use user's waptconsole.ini configuration file instead of wapt-get.ini for the commands targeted to package development ('sources','make-template', 'make-host-template','make-group-template','build-package','sign-package','build-upload','duplicate','edit','edit-host','upload-package','update-packages'. This avoids the need to write these parameters in wapt-get.ini on the development workstation. These parameters are not shared across multiple users on same machine. One use case is to allow multiple profiles (key, upload location) depending on the maturity of package (development, test, production...) Setuphelpers * [ADD] helper functions dir_is_empty, file_is_locked, service_restart and WindowsVersions class * [UPD] Added referer and user_agent in "wget" and "wgets" * [UPD] run function : define stdin as PIPE to avoid lockup process waiting for input or error like unable to duplicate handle when using for example powershell * [UPD] Version class : try to compare version using at least Version.members_count * [FIX] encoding fixes for registry functions, fix encoding for registry_setstring key name * [FIX] install_exe_if_needed : don't check uninstall_key or min_version if not provided * [FIX] install_exe_if_needed and install_msi_if_needed version check if --force * [UPD] Check version and uninstall key after install with install_msi_if_needed and install_exe_if_needed * [UPD] inventory includes informations from WMI.Win32_OperatingSystem * [ADD] get_disk_free_space helper function * [UPD] check free disk space when downloading with wget. check http status before. * [UPD] Version class : Version('7')<Version('7.1') should return True wapt-get * [ADD] 2 commands to get server SSL certificate and activate the certificate checking when using https with waptserver * {FIX] get_sources to allow svn checkout of a new ppackage project * [FIX] wapt-get register problems with some BIOS with bitmaps * [UPD] Check uninstall key after package install if uninstallkey is provided * [FIX] added compatibility OS in manifest file for wapt-get and waptconsole version windows * [FIX] erroneous error messages for wapt-get session-setup console * [UPD] add "pattern" parameter to all_files function * [FIX] Install Date incorrectly registered by setuphelpers.register_uninstall * [ADD] user_local_appdata function * [ADD] add the signer CN and signer_fingerprint to control file when building package * [ADD]add control attributes min_wapt_version to trigger an exception if Package requires a minimum level of libraries. The version is checked againts setuphelpers.py 's __version__ attribute. * [ADD] authorized_certificates attribute is sent to wapt server. It contains the list of host's signer certificates distributed on the host * [FIX] When signing, check if wapt zip file has already a signature file. (python zipfile can not replace the file inline) * waptservice * {ADD] Show all versions checkbox in Available packages page * [UPD] Skin updated * {ADD] filter searchbox for avalable packages waptconsole * [ADD]Add NOT checkbox for keywords search in waptconsole to search for hosts NOT having a specific package or software... * [FIX] fix integer limit for grid display of package size, use int64 for size of packages in waptconsole. * [UPD] don't list packages of section "restricted" in local webservice available packages list * [UPD] CommonName attribute should be populated now, so that signer identity is not None in package control file. * [ADD] signer's identity column in packages grid * [FIX] escape quotes in package's description * [ADD] Check waptagent.exe version against waptsetup-tis version at waptconsole startup. * [UPD] try to display a progress dialog at waptconsole startup * [FIX] company not set when building customized waptagent.exe * [ADD] initialize organization in waptagent.exe build with CN from certificate. waptexit * [UPD] some text introduction changes waptray : * [NEW] Limit trayicon balloon popup when Windows version is above Windows 7 or if notify_user=0 in wapt-get.ini waptserver * [UPD] Use broadcast address on interface for wakeonlan call * [FIX] remove the check of wapt server password which prevent the proper registration of waptserver on Windows. * [UPD] when upgrading, reuse existing waptserver ini file if already exists, don't overwrite server_uuid and ask for password reset if it already exists waptdeploy/waptupgrade * [FIX] waptdeploy not working on WinXP removed DisableWow64FileSystemRedir on runtask. * [FIX] waptupgrade : Missing quotes for system account on Windows XP Libraries * [ADD] BeautifulSoup for wapt packages auto updates tasks * [UPD] winsys library update to '1.0b1' -- 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

2 1

Re: [Wapt] Accès serveur apache souvent en rade
by Nathanaël Hannebert 04 Nov '16

04 Nov '16

Bonjour à tous, Je suis confronté à ce même problème. J’ai une VM Debian avec un bureau (MATE). Je vais donc réinstaller une VM sans bureau graphique, étant donné que cela semble résoudre le problème. Cordialement, Nathanaël HANNEBERT Services Généraux [LOGOTHUND] Cabinet LEFEUVRE 2 rue de Rieux 44018 NANTES Cedex 1 Maintenance : 02.51.72.94.73 Ligne interne : 473 Ligne directe : 02.23.44.25.74 www.lefeuvre-immobilier.com<http://www.lefeuvre-immobilier.com/> [Wapt] Accès serveur apache souvent en rade [RESOLU] Latieule Joel joel.latieule at ac-montpellier.fr <mailto:wapt%40lists.tranquil.it?Subject=Re%3A%20%5BWapt%5D%0A%20%3D%3Futf-8%3Fq%3FAcc%3DC3%3DA8s_serveur_apache_souvent_en_rade_%3D5BRES%3F%3D%0A%20%3D%3Futf-8%3Fq%3FOLU%3D5D%3F%3D&In-Reply-To=%3C55962679.3040309%40ac-montpellier.fr%3E> Fri Jul 3 08:06:49 CEST 2015 * Previous message: [Wapt] Deploiment groupe de paquet Grp ActiveDirectory <http://lists.tranquil.it/pipermail/wapt/2015-July/001068.html> * Next message: [Wapt] Unable to get host <http://lists.tranquil.it/pipermail/wapt/2015-July/001059.html> * Messages sorted by: [ date ]<http://lists.tranquil.it/pipermail/wapt/2015-July/date.html#1058> [ thread ]<http://lists.tranquil.it/pipermail/wapt/2015-July/thread.html#1058> [ subject ]<http://lists.tranquil.it/pipermail/wapt/2015-July/subject.html#1058> [ author ]<http://lists.tranquil.it/pipermail/wapt/2015-July/author.html#1058> ________________________________ Bonjour, Après avoir supprimé tous les desktop le problème persistait. J'ai refait une installation neuve sans aucun gestionnaire de bureau et depuis ce problème est résolu. D'autres problèmes viennent d'apparaitre mais je vais ouvrir un autre sujet. Merci à tous pour vos réponses Cordialement, Latieule Joël - TICE / Collège Jules Ferry de Narbonne Le 30/06/2015 13:54, Latieule Joel a écrit : > Je viens de dé-installer toute l'interface graphique et j'ai le bon > vieux terminal comme écran. > > Il me reste plus qu'à attendre quelques jours pour vérifier si le > problème ce répète. > > > > > Cordialement, Latieule Joël - TICE / Collège Jules Ferry de Narbonne > > Le 23/06/2015 12:31, Denis Cardon a écrit : >> Bonjour Claude, >> >> (j'ai remis wapt at list.tranquil.it<http://lists.tranquil.it/listinfo/wapt> 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 at tranquil-it-systems.fr<http://lists.tranquil.it/listinfo/wapt> >>> <mailto:denis.cardon at tranquil-it-systems.fr<http://lists.tranquil.it/listinfo/wapt>>> 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 at srv-omv<http://lists.tranquil.it/listinfo/wapt>:/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 at srv-omv<http://lists.tranquil.it/listinfo/wapt>:/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 at srvwapt.tranq<http://lists.tranquil.it/listinfo/wapt> 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 at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt> >>> <mailto:WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt>> >>> http://lists.tranquil.it/listinfo/wapt >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> WAPT mailing list >>> WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt> >>> <mailto:WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt>> >>> http://lists.tranquil.it/listinfo/wapt >>> >>> >>> >>> >>> _______________________________________________ >>> WAPT mailing list >>> WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt> >>> <mailto:WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt>> >>> http://lists.tranquil.it/listinfo/wapt >>> >>> >>> >>> >>> _______________________________________________ >>> WAPT mailing list >>> WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt> <mailto:WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt>> >>> 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 at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt> <mailto:WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt>> >>> http://lists.tranquil.it/listinfo/wapt >>> >>> >> > > _______________________________________________ > WAPT mailing list > WAPT at lists.tranquil.it<http://lists.tranquil.it/listinfo/wapt> > http://lists.tranquil.it/listinfo/wapt ________________________________ * Previous message: [Wapt] Deploiment groupe de paquet Grp ActiveDirectory <http://lists.tranquil.it/pipermail/wapt/2015-July/001068.html> * Next message: [Wapt] Unable to get host <http://lists.tranquil.it/pipermail/wapt/2015-July/001059.html> * Messages sorted by: [ date ]<http://lists.tranquil.it/pipermail/wapt/2015-July/date.html#1058> [ thread ]<http://lists.tranquil.it/pipermail/wapt/2015-July/thread.html#1058> [ subject ]<http://lists.tranquil.it/pipermail/wapt/2015-July/subject.html#1058> [ author ]<http://lists.tranquil.it/pipermail/wapt/2015-July/author.html#1058> ________________________________ More information about the WAPT mailing list<http://lists.tranquil.it/listinfo/wapt>

2 1

Problème de téléchargement de flashplayer depuis le repo TIS
by Jean-Charles GRANGER 04 Nov '16

04 Nov '16

Bonjour, La console WAPT refuse de récupérer le package Flash Player depuis le repository TIS : Suis-je le seul à avoir ce souci ? Cordialement, JCG -- Jean-Charles GRANGER Unité Informatique du Campus Antenne du Coeur d'Ecole Montpellier SupAgro / INRA Montpellier

2 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

WAPT