Classement

J'ai fait quelques modifications pour accéder aux répertoires glpi via un simple explorateur de fichiers. Pour me connecter à mon NAS, j'utilise un code utilisateur qui est administrateurs mais qui n'est pas admin ou root. Via FileStation, j'ai constaté que le répertoire glpi avait "http" comme utilisateur propriétaire et comme groupe. L'utilisateur "http" n'existe pas, le groupe oui. J'ai commencé par me rajouter à ce groupe mais cela ne suffit pas à me permettre de créer des répertoires ou de copier des fichiers. Je me suis ensuite mis comme propriétaire puis j'ai mis le groupe des administrateurs à la place de http. Pas de problème pour accéder/créer/modifier les fichiers et répertoires mais "accès refusé" à la connexion glpi !!!! Finalement, j'ai du ajouter les droits lire/écrire/exécuter via FileStation (onglet permissions) sur le répertoire glpi aux "autres" pour que la connexion marche à nouveau. Il me semble que ce n'est pas très sécurisé et je cherche encore ce que j'ai raté dans les droits d'accès Synology. A suivre....

Bon, après plusieurs tests et contrôles préalables, j'arrive maintenant à me déconnecter / reconnecter sans problème. Le soucis devait donc venir de la version du plugins FusionInventory. Pour éviter une réinstallation par erreur, j'ai renommé comme préconisé le fichier glpi/install/install.php en install.php.ori pour le rendre inexécutable. Il me reste à résoudre le problème des droits d'accès sur le répertoire glpi. A suivre....

J'essaye de voir comment debugger le script glpi/index.php mais je n'ai pas encore trouvé d'outil simple pour voir son exécution pas à pas. J'ai fait quelques tests : - si tu supprimes le fichier glpi/config/config-db.php, on peut alors se reconnecter à glpi. Celui-ci demande les identifiants de connexion à la base MariaDB !! (ceux qui sont dans config-db.php) et demande si on veut faire une installation ou des mises à jour - si tu sélectionnes mises à jour, il propose la liste des bases de données MySQL, j'ai choisi bien sûr celle de glpi - une fois la mise à jour faite, j'ai accès à ma base de données normalement. J'ai découvert que la mise à jour avait au préalable réalisée une sauvegarde de ma base version 0.83.3 au format xml et sql Je suis ensuite aller voir mes plugins et aucun plugin FusionInventory n'apparaissaient (je n'en ai pas d'autres). Via FileStation, j'ai copié les plugins dans un répertoire backup (/glpi/plugins dans /glpi/plugins/backup) puis j'ai copié la nouvelle version 0.84 2.1 de Fusion Inventory dans glpi/plugins. Curieusement, je ne peux pas copier mes fichiers sans passer par l'utilisateur administrateur de mon DSM. Je l'ai fait via ftp. A partir de la, les plugins sont réapparus dans glpi avec 3 plugins à nettoyer (Déploiement FusionInventory, Fusion Inventory INVENTORY et FusionInventory SNMP, tous en 0.83) et un à mettre à jour/nettoyer (FusionInventory 0.84). Nettoyer voulant dire supprimer je suppose. Après avoir nettoyé les 3 premiers et mis à jour le 4ème, j'ai pu activer le plugin FusionInventory en version 0.84. J'ai ensuite provoqué un inventaire sur un poste de travail pour vérifier que tout marche et .... ca marche : un poste PC et un poste Android ont bien réussi à envoyer leur inventaire respectif. Reste plus qu'à me déconnecter et à me reconnecter pour voir. Avant de tenter l'opération, je vais consulter et vérifier tous les paramètres via l'interface web. Je poste ce premier message avant de tout perdre et vous tiens au courant.

Tu peux essayer de recherche les dernier thumbs qu'il a généré, la photo qui le fait planter devrait être à proximité Quelque chose dans le genre de: find /volume1 -type f -iname '*thumb*' -mtime -1 | xargs ls -l puis rechercher les plus récentes dans le résultat obtenu pourrait mener à quelque chose.

Voici la liste des modules disponibles sous DSM 5.0 dans /etc/httpd/modules. Comme dit précédemment, il suffit de les activer dans /etc/httpd/conf/httpd.conf-user. mod_auth_digest.so mod_authn_alias.so mod_authn_anon.so mod_authn_dbd.so mod_authn_dbm.so mod_authn_default.so mod_authn_file.so mod_authnz_ldap.so mod_authz_dbm.so mod_authz_groupfile.so mod_authz_owner.so mod_authz_user.so mod_cache.so mod_caldav.so mod_cern_meta.so mod_charset_lite.so mod_dav.so mod_dav_fs.so mod_dav_lock.so mod_davacl.so mod_dbd.so mod_deflate.so mod_disk_cache.so mod_dumpio.so mod_expires.so mod_ext_filter.so mod_fastcgi.so mod_file_cache.so mod_headers.so mod_ident.so mod_imagemap.so mod_info.so mod_ldap.so mod_log_forensic.so mod_logio.so mod_mem_cache.so mod_proxy.so mod_proxy_ajp.so mod_proxy_balancer.so mod_proxy_connect.so mod_proxy_ftp.so mod_proxy_http.so mod_proxy_scgi.so mod_reqtimeout.so mod_rewrite.so mod_spdy.so mod_speling.so mod_ssl.so mod_ssl_npn.so mod_status.so mod_substitute.so mod_suphp.so mod_synobandwidth.so mod_unique_id.so mod_usertrack.so mod_version.so mod_vhost_alias.so mod_xsendfile.so

**IMPORTANT** la manip décrite est un peu modifiée avec DSM 5.0: L'emplacement du fichier httpd.conf-user à changé (dans "/etc/httpd/conf" maintenant) la commande de redémarrage apache est: /usr/syno/sbin/synoservicecfg --restart httpd-user Attention: en cas d'erreurs de syntaxe ou autre le service ne sera pas redémarré mais rien ne le signale au terminal. Il est conseillé d'aller visualiser les dernières lignes du fichier "/var/log/upstart/httpd-user.log" pour s'assurer que le restart s'est bien passé. Tout d'abord je tiens a citer le travail de PatrickH dont le tuto doit être considéré comme la base de ce qui va suivre J'en recommande chaudement la lecture préalable si vous voulez comprendre tout ce qui suit. Dans la suite il sera supposé que vous disposez de votre nom de domaine que nous appellerons "mondomaine.com" Tous les sous-domaines utilisés par la suite (<sous-domaine>.mondomaine.com donc ) devront avoir été déclarés dans votre console d'administration de nom de domaine et pointer vers votre ip externe. A noter qu'il est aussi possible d'appliquer ce qui suit dans le cas des sous-domaine DDNS fourni par Synology (du style par exemple "monnas.synology.me"). On utilisera dans ce cas des sous-domaine de niveau2 (soudomaine.monnas.synology.me) sans avoir besoin à les déclarer, c'est automatique dans ce cas. Les redirections de ports pour les connexions externe sur les ports et 443 devront aussi avoir été mises en oeuvre dans le routeur ou la box à destination de l'IP sur le réseau interne du Syno. Toutes les opérations suivantes doivent s'exécuter en étant connecté sur le Syno en ligne de commande (via ssh ou telnet) sur le compte "root" pre-requis le service web station doit être activé (panneau de config->services web->applications wev->activer web station) si on souhaite aussi se connecter en https, il que l'option panneau de config->services web->Service Http->activer la connexion HTTPS pour les services web soit activée. ajouter la ligne suivante *à la fin* de /usr/syno/apache/conf/httpd.conf-user include /usr/local/etc/http.d/revproxy.conf Attention: cette opération devra être effectuée de nouveau en cas d'upgrade firmware DSM. (mais ce sera la seule chose à faire dans ce cas, tout ce qui est décrit ci dessous sera préservé) Créer le répertoire "/usr/local/etc/http.d" mkdir -p /usr/local/etc/http.d Tous le blocs de configurations décrits dessous seront à mettre dans /usr/local/etc/http.d/revproxy.conf dans l'ordre. Première partie - chargement des modules (tous ne sont pas nécessaires mais peuvent servir pour d'autres types de configs, par exemple le module "mod_proxy_ftp" permet par exemple d’accéder de l'extérieur à un serveur ftp freebox en http. <IfModule !proxy_module> LoadModule proxy_module modules/mod_proxy.so </IfModule> <IfModule !proxy_connect_module> LoadModule proxy_connect_module modules/mod_proxy_connect.so </IfModule> <IfModule !proxy_http_module> LoadModule proxy_http_module modules/mod_proxy_http.so </IfModule> <IfModule !proxy_ftp_module> LoadModule proxy_ftp_module modules/mod_proxy_ftp.so </IfModule> Obligatoire avant la suite NameVirtualHost *: <VirtualHost *:> ServerName * DocumentRoot /var/services/web </VirtualHost> 2ème partie - acces aux sevices DSM en http Ajouter le bloc suivant. (le nom "dsm" est un exemple). Dans le cas d'un domaine DDNS fourni par synology on aura par exemple "dsm.monnas.synology.me" <VirtualHost *:> ServerName dsm.mondomaine.com ProxyPass / http://localhost:5000/ ProxyPassReverse / http://localhost:5000/ </VirtualHost> Cette simple config permet de se connecter sur le port a l'interface dsm, en utilisant l'url http://dsm.mondomaine.com accès direct à filestation (sous réserve que le port 7000 ait affecté a file station dans le "portail des applications" du panneau de configuration) <VirtualHost *:> ServerName filestation.mondomaine.com ProxyPass / http://localhost:7000/ ProxyPassReverse / http://localhost:7000/ </VirtualHost> Ce qui donnera acces de façon similaire a filestation en http sur le port via l'url http://filestation.mondomaine.com. On procèdera de façon similaire pour les autres services tels qu'audiostation, downloadstation, webdav, etc ... en choisissant a chaque fois un nom de sous-domaine différent et le numéro de port correspondant. 3eme partie - acces https (SSL) Cette partie du fichier de config devra être précédée de la ligne: NameVirtualHost *:443 On va ensuite ajouter des blocs "VirtualHost" pour tous les services auquel on veit pouvoir accéder en https en sur le port 443 Cas de l'acces à l'interface DSM: <VirtualHost *:443> ServerName webman.mondomaine.com SSLCipherSuite HIGH:MEDIUM SSLProtocol all -SSLv2 SSLCertificateFile /usr/syno/etc/ssl/ssl.crt/server.crt SSLCertificateKeyFile /usr/syno/etc/ssl/ssl.key/server.key SSLEngine on SSLProxyEngine on ProxyPass / https://localhost:5001/ ProxyPassReverse / https://localhost:5001/ </VirtualHost> Pour les autres services, on déclinera cela de façon similaire à ce que l'on a fait plus haut dans le cas http, en dupliquant le bloc ci dessus, puis en éditant dans la copie les lignes des clauses ServerName, ProxyPass et ProxyPassReverse. (attention à ne pas se tromper sur les numéros de ports utilisés en mode SSL, celui par défaut de filestation est 7001 par exemple, cf le portail des applications) prise en compte des modifications Pour cela, il est nécessaire de rédémarrer le serveur apache. Utiliser la commande: /usr/syno/etc/rc.d/S97apache-user.sh restart