Aller au contenu

Just1

Membres
  • Compteur de contenus

    45
  • Inscription

  • Dernière visite

Messages posté(e)s par Just1

  1. (Merci à parisbyday qui m'a aidé à retrouver une configuration IPKG normale après la perte d'un de mes fichiers)

    La Led bleu clignote et la seule solution est de faire un arret brute force.

    J'avais exactement les mêmes symptômes. Le fait est que le NAS se bloque en pleine procédure d'arrêt. Peut-être que tu peux déjà vérifier si tes logs (/var/log/messages) ont des lignes similaires à celles de mon premier post.

    Ci c'est le cas, tu peux pousser encore un peu en lançant une session SSH et en exécutant les deux lignes de script du 12ème post de ce topic. Ensuite, essaye d'arrêter ton NAS. Si ça marche, tu as gagné ! Je posterai très bientôt ma solution "définitive", avec des scripts propres et leur emplacement exact.

    Sinon, il faudra s'arracher encore quelques cheveux. Mais poste ici tes résulats wink.png

  2. Ça maaaaaaaaaarche !!

    Sur cette même page de wiki, j'avais oublié de tester le optware.sh placé dans /usr/local/etc/rc.d/ (aux côtés de phpMyAdmin.sh et deMailStation.sh). J'ai tellement testé de trucs que j'ai fini par oublié celui-là... J'ai pris texto le script proposé, et ça fonctionne cool.png Comme quoi dans ce répertoire un fichier qui s'appelle "nimportequoi.sh" s'exécute, alors qu'on fichier "Kxx.sh" non (dans ma situation) !

    
    #!/bin/sh
    
    #
    
    # Optware setup
    
    # Alternatives Optware Startup und Shutdown Script #/usr/local/etc/rc.d/optware.sh
    
    #
    
    case $1 in
    
    start)
    
    	   for i in /opt/etc/init.d/S??* ;do
    
    #
    
    			   # Ignore dangling symlinks (if any).
    
    			   [ ! -f "$i" ] && continue
    
    #
    
    			   case "$i" in
    
    				  *.sh)
    
    					   # Source shell script for speed.
    
    					   (
    
    							   trap - INT QUIT TSTP
    
    							   set start
    
    							   . $i
    
    					   )
    
    					   ;;
    
    				  *)
    
    					   # No sh extension, so fork subprocess.
    
    					   $i start
    
    					   ;;
    
    			   esac
    
    	   done
    
    	   ;;
    
    #
    
    stop)
    
    #
    
    	   for i in /opt/etc/init.d/S??* ;do
    
    #
    
    			   # Ignore dangling symlinks (if any).
    
    			   [ ! -f "$i" ] && continue
    
    #
    
    			   case "$i" in
    
    				  *.sh)
    
    					   # Source shell script for speed.
    
    					   (
    
    							   trap - INT QUIT TSTP
    
    							   set stop
    
    							  . $i
    
    					   )
    
    					   ;;
    
    				  *)
    
    					   # No sh extension, so fork subprocess.
    
    					   $i stop					   ;;
    
    			   esac
    
    		 done
    
    		 ;;
    
    #
    
    *)
    
    		 echo "Usage: $0 [start|stop]"
    
    		 ;;
    
    esac
    
    #
    
    # End
    
    

    Je suis SOULAGÉ, mon NAS peut maintenant enfin s'arrêter et redémarrer sans l'éteindre par la méthode "bruteforce" (en Français je dirais "bourrin" wink.png ).

    Allez je me permets une dernière question : est-ce que /usr/local/etc/rc.d/ est l'endroit le plus adapté pour accueillir un tel script "optware.sh" ? Dans la mesure du possible j'aimerais avoir tous dans /opt/...

  3. 1) placer le script dans /opt/etc/init.d/

    Ça c'est ce que je fais depuis le début, sur les conseils de Patrick. Mais pour la peine, j'ai aussi essayé de placer mon script (K01shutdown.sh) dans /usr/syno/etc/rc.d/ , et aucun changement significatif... Et parce que je suis généreux, je fais aussi un essai avec /usr/local/etc/rc.d/ , mais rien de plus. Et puis /etc/init.d/ aussi tiens ! Non plus...

    2) http://forum.synolog...Spindown_issues

    Regarde la partie "noatime" et le STEP2 du diagnosis

    J'ai essayé de rediriger le cache vers /opt/lib , mais même après 3 redémarrage (et même pas de fichier /etc/ld.so.config), ça n'a aucun effet chez moi.

    Puis j'ai continué à chercher, et je suis tombé sur une page de wiki Synonology en allemand traitant de IPKG. Comme je ne comprends pas un mot d'allemand, je remercie Google de fournir également un traducteur biggrin.png Assez nul dans ce cas là d'ailleurs, puisque les mots-clés des scripts sont également traduits tongue.png

    Mais cette lecture m'a permis, avec quelques farfouilles dans le NAS, de comprendre la suite logique des événements :

    /etc/rc.local > /etc/rc.optware > /opt/etc/rc.optware

    En très gros, voici ce que donne le contenu de ces scripts :

    /etc/rc.local :

    
    /etc/rc.optware start
    
    
    /etc/rc.optware :
    
    start)
    
    	mkdir /opt
    
    	mount -o bind ${REAL_OPT_DIR} /opt
    
    	/opt/etc/rc.optware
    
    stop)
    
    	echo "Shutting down Optware"
    
    
    /opt/etc/rc.optware :
    
    for i in /opt/etc/init.d/S??* ;do
    
    	(lancement des programmes avec l'attribut "start")
    
    
    Après l'ajout de quelques lignes d'écriture vers un fichier depuis les 2 premiers scripts, je constate qu'ils ne sont lancés que lors du démarrage.
    
    Mon Jan 9 22:00:25 CET 2012+ : /etc/rc.local
    
    Mon Jan 9 22:00:25 CET 2012+ : /etc/rc.optware start
    
    

    Cela explique en partie pourquoi mon script perso n'est jamais appelé avec l'option "stop".

    Arrivés là, je vois 2 possibilités :

    • soit il existe un équivalent de rc.local pour le shutdown, et dans ce cas je serais très heureux que quelqu'un me l'apprenne, comme ça je pourrais lancer /etc/rc.optware en mode "stop", et ainsi de suite
    • soit il faut agir à un endroit qui m'est encore parfaitement inconnu...

    Mais où diable se cache le script qui se charge du démontage des volumes ?? Et pourquoi fetchmail aurait prévu une séquence de "stop" dans son script de lancement si celui-ci n'est jamais exécuté ?

    Je crois que ça y est, l'univers Linux m'envahit dry.png

  4. J'ai essayé, sans succès. J'ai même dupliqué le fichier (un K01, et un autre K99) : aucun des deux ne se lance !

    Par contre, j'ai également fait une copie sous le nom de "S99***.sh", et là il se lance au "start" (je le vois de mon fichier de log "perso"), mais jamais au "stop".

    Ma conclusion est la suivante : les scripts d'arrêts (Kxx) d'ipkg ne sont pas lancés.

    D'ailleurs dans le script de démarrage de fetchmail (S52fetchmail), il y a aussi des instructions pour l'arrêt...

    
    #!/bin/sh
    
    PROG=fetchmail
    
    ARGS="-d 300 -t 60 -a -e 50 --auth password -f /opt/etc/fetchmailrc -L /opt/var/log/fetchmail"
    
    if [ -z "$1" ] ; then
    
        case `echo "$0" | /bin/sed 's/^.*\/\(.*\)/\1/g'` in
    
    	    S??*) rc="start" ;;
    
    	    K??*) rc="stop" ;;
    
    	    *) rc="usage" ;;
    
        esac
    
    else
    
        rc="$1"
    
    fi
    
    case "$rc" in
    
        start)
    
    	    echo "starting service $PROG"
    
    	    $PROG $ARGS 2>&1
    
    	    ;;
    
        stop)
    
    	    echo "stopping service $PROG"
    
    	    if [ -n "`/opt/bin/pidof $PROG`" ]; then
    
    		    /opt/bin/killall $PROG
    
    	    fi
    
    	    ;;
    
        restart)
    
    	    "$0" stop
    
    	    sleep 1
    
    	    "$0" start
    
    	    ;;
    
        *)
    
    	    echo "Usage: $0 (start|stop|restart|usage)"
    
    	    ;;
    
    esac
    
    

    Si je comprends bien il y a une sorte de bidouille pour interpréter les K** comme un "stop", mais je ne suis pas bien sûr de tout comprendre, surtout que je suis loin d'être un tueur en expressions régulières.

    Une explication ? Patrick peut-être ?

  5. (En fait ça fonctionne comme les scripts Windows, donc j'aurais dû me douter de la syntaxe.)

    En considérant que le point de montage /opt existe toujours au moment de l'exécution du script (puisque ce serait la raison de mon problème : arrêt impossible cause démontage impossible de /opt), j'ai rajouté une ligne à chaque cas possible de mon script :

    
    echo $(date)+" : x_x" >> /opt/etc/init.d/log.txt
    
    
    "x_x" vaut "start", "stop", ou "default" en fonction des cas. Quand je le lance à la main, encore une fois ça fonctionne. Mais le script ne semble pas être lancé par le système lors de l'arrêt (aucune entrée dans mon fichier) ! A moins évidemment que /opt n'existe plus... huh.png Pourtant les log systèmes disent toujours :
    
    force umount failed! mnt_count:2
    
    

  6. Lancé manuellement avec ta ligne d'appel, tout baigne.

    Ça se complique lorsque je cherche à arrêter ou redémarrer le serveur sans lancer manuellement le script au préalable. Il faudrait que je sache comment et quand mon script est exécuté (si c'est le cas) : ça serait pas mal si j'écrivais une ligne dans les log... Une idée pour faire ça ?

  7. J'ai dû faire une erreur de frappe au début, et ça ne marchait pas.

    J'ai donc ré-essayé, et en tapant dans la ligne de commande :

    
    PNAME=`ps |grep "/opt/" |grep -v "grep" |awk -F" " '{ print $1 }'`
    
    kill $PNAME
    
    
    ça marche au poil. D'ailleurs,
    
    ps |grep "/opt/" |grep -v "grep" |awk -F" " '{ print $1 }'
    
    

    me renvoie les bons PID.

    Par contre, si j'intègre ces deux lignes à mon précédent post au script de mon précédent post, ça ne fonctionne pas ! Alors que la version que j'ai copié-collé ici tout à l'heure fonctionne... C'est à n'y rien comprendre.

  8. @bud : Je ne comprends pas bien l'utilisation de 'awk'. En plus lorsque je tape la ligne dans la console, je perds la main ; quand c'est dans le script d'arrêt, ça ne fonctionne pas.

    Voici donc mon fichier K99_kill_opt_processes.sh placé dans /opt/etc/init.d/

    
    case $1 in
    
    
    start)
    
    ;;
    
    
    stop)
    
    PNAME=`ps |grep "/opt/" |grep -v "grep"`
    
    killall $PNAME
    
    ;;
    
    
    *)
    
    ;;
    
    
    esac
    
    

    Je me suis permis de modifier la ligne du 'ps' avec un slash final pour "/opt/" (on ne sait jamais...) et grep entre guillemets pour être plus clair dans ' grep -v "grep" ' (exclusion du programme grep qui s'exécuterait dans /opt/).

    Tel quel ça fonctionne chez moi, donc je le garde !

    Merci à tous les deux.

    Si un modérateur pouvait déplacer ce sujet vers le forum "Modifications logicielles", où il aurait certainement plus sa place, je le remercie d'avance. A vous de juger smile.png

  9. Et moi je le placerais dans /opt/etc/init.d car si tu le mets dans /usr/syno/etc.defaults/rc.d il risque d'être écrasé lors d'une mise à jour du firmware.

    Merci à vous deux. Je vais essayer ça dès que possible.

    Petite question supplémentaire cependant : le script une fois placé dans /opt/etc/init.d est-il en "lieu sûr" ? (à l'abri d'une mise à jour de IPKG, ou de l'installation/désinstallation d'un paquet ?).

  10. OK alors je ne peux pas le faire tel quel car le système me répond :

    
    umount: can't umount /opt: Device or resource busy
    
    
    ce qui est logique puisque des programmes sont en cours d'exécution. Et là je me dis : "Si le système n'arrive pas à exécuter "umount" à la demande, c'est certainement qu'il n'arrive pas non plus à le faire lors de la procédure d'arrêt de la machine..." Sans aller jusqu'à "umount /opt", j'essaye donc de tuer les programmes IPKG en cours d'exécution. Pour cela, je les liste avec :
    
    ps | grep "/opt/"
    
    
    (Chez moi il y a "saslauthd" et "icecast" qui s'exécutent.) Puis, pour chaque élément de la liste, je tue le programme :
    
    killall mon_programme
    
    

    Et là évidemment j'essaye un reboot : ça fonctionne. Ce sont donc les programmes en cours d'exécution qui empêchent l'arrêt. Ça paraît tellement logique, et pourtant je n'y avais pas pensé...

    Merci bud77.

    Mais maintenant se pose une autre question : Comment moi, novice en Linux, je peux faire un script pour arrêter tous les programmes IPKG lors du shutdown (en utilisant par exemple le résultat de ' ps | grep "/opt/" ') ? Et où dois-je placer ces lignes de script ?

  11. Dans le post n°34 de ce topic, vous trouverez l'ensemble des informations concernant ce problème, ainsi qu'une solution permettant de le résoudre durablement. Ne perdez pas de temps, cliquez sur le lien !

    Ce topic a donné lieu à l'écriture d'un tutoriel que je vous conseille de consulter dès maintenant !

     

    Bonjour à tous,

    Depuis quelques temps j'ai un problème qui m'embête pas mal, alors après quelques investigations qui m'ont apporté des infos supplémentaires, je m'en remets à la communauté des experts wink.png

     

    IPKG est installé sur mon DS710+, notamment pour Icecast et SVN (qui me sert beaucoup en ce moment). Il y a quelques mois, lors de la sortie de TimeBackup, j'avais eu des soucis : impossible de lancer l'application. Après contact du support Synology, ils m'ont dit que c'était à cause d'IPKG, qui montait /opt au démarrage, et résultat TimeBackup n'arrivait pas à faire son premier lancement.

    Le problème que j'ai en ce moment est du même goût (en termes de cause) : impossible d'arrêter ou de redémarrer le Syno (obligé de rester appuyé sur le bouton jusqu'à coupure de l'alimentation). J'ai donc essayé de neutraliser IPKG, et là magie : je peux arrêter la machine ! Je ré-active IPKG, et je désinstalle tous les paquets officiels dont je ne me servais pas (dont TimeBackup). Il ne me reste alors que MailStation et phpMyAdmin.

     

    Mais le problème est indemne : IPKG empêche l'arrêt de ma machine. Après extraction des logs, voici les lignes supplémentaires dans le cas ou l'arrêt ne fonctionne pas :

     

     
    
    kernel: [2484412.625955] force umount failed! mnt_count:2
    
    kernel: [2484413.679016] device-mapper: ioctl: unable to remove open device vol1-origin
    
    syno_poweroff_task: space_snapshot_origin.c:354 Deleting snapshot-origin of /dev/md2 fail
    
    

     

     

    Pour info : ipkg version 0.99.163

     

    Quelqu'un a-t-il déjà rencontré ce problème ? Peut-il être dû à un seul des paquets IPKG installé, et si oui lequel ?

    Un script à l'extinction pourrait-il résoudre le problème ?

     

    Merci à tous, et bonne année 2012 cool.png

  12. Après avoir réfléchi et laissé s'écouler un peu de temps, j'ai opté pour la solution de la copie "pseudo-manuelle". C'est certes la solution la plus simple (et même un peu "simpliste"), mais finalement c'est celle qui correspond le mieux à mon cahier des charges (merci à Big Jim wink.gif).


    donc dans ta situation, j'opterai pour une copie manuelle des e-mails de plus de 3 mois (ou tout simplement quand ta boite mail est trop pleine).
    pour cela, en configurant ton syno avec Mail station,
    en visualisant le compte imap de ton mailstation sur thunderbird
    Copier / coller les "vieux e-mails" sur ton syno.

    donc tu auras les message recent sur le Webmail de ton fournisseur
    et les messages anciens sur le syno.
    PS: Le couper / coller conserve le statut lu/nonlu des messages


    Malheureusement, mes utilisateurs ne sont pas tous très disciplinés... donc je continue à creuser dans le sens d'une automatisation.
    Pour l'instant je n'ai pas sorti l'artillerie lourde car je n'ai pas pris le temps de creuser du côté des scripts de synchro.

    J'obtiens quelque chose de "pseudo-manuel" car j'ai voulu tenté d'utiliser les filtres pour déplacer mon courrier à archiver. C'est facile à mettre en place (surtout pour avoir un résultat rapide, histoire de tester), et ça devrait être possible de la même manière sous Thunderbird, Outlook, et Windows Mail (à vérifier par la suite).
    Je ne peux pas encore me prononcer sur l'efficacité de cette solution, mais je suis en phase de test depuis hier soir, et je ne manquerais pas de faire un feedback ici dès que j'ai du nouveau. Je peux d'ores et déjà dire que mon "organisation" me pose un petit problème : gérer la synchro d'une arborescence complexe (dossiers, sous-dossiers, etc.) entre deux comptes IMAP avec les filtres semble difficilement réalisable (il faudrait apparemment autant de filtres que de dossiers...).

    Prochaine étape : se renseigner de manière approfondie sur des scripts comme offlineimap. (Mais avant ça je m'occupe du formatage de mon PC, et de l'installation d'OpenLDAP...)
  13. Nativement le syno ne permet pas de faire cela.

    Mais tu regarderas sur le forum 2 choses :

    - ipkg : c est un système automatiser d installation d'application standard de Linux que le syno

    - fetchmail : que tu pourras installer avec ipkg qui permet de venir charger des mails depuis d autres serveur sur mailstation, il me semble qu il y a des options sur l'ancienneté mais il faudra que tu vérifies.

    Merci pour IPKG, mais il suffisait de regarder ma signature pour comprendre que je l'utilisais déjà:P.

    Pour ce qui est de fetchmail, j'ai lu deux fois la liste de toutes les options dans la doc : il y a des options d'ancienneté, mais il n'y en n'a pas qui correspondent à "récupérer les mails de plus de X jours".

    sinon, je sais qu'il existe des outils de synchro Imap (Imapsync: offlineimap)

    en cherchant un peu offlineimap pourrait peut etre t'etre utile et devrait pouvoir s'installer sur le syno.

    http://offlineimap.org/

    http://saimon.org/lo...fflineimap.html

    Ça pourrait correspondre à mes besoins, en tout cas vu de loin. Je vais creuser de ce côté-là, et je reviendrais par ici quand ça aura bougé.

    Merci de vos réponses ;)

  14. Bonjour à tous,

    Je souhaiterais vous faire part d'une situation que je rencontre actuellement sur mon DS710+ et qui va me poser des soucis (donc pour lequel je cherche une solution).

    Voici le contexte :

    Justin est un utilisateur, non administrateur

    "sono" est un dossier partagé du NAS (caché dans "Mes emplacements réseau")

    Les 2 groupes auquels Justin appartient n'ont pas accès à "sono", mais Justin possède l'accès RW.

    (Aucun privilège NFS configuré.)

    L'accès au navigateur de fichiers est autorisé pour Justin.

    FileStation est désactivé (mais même actif cela ne change rien à mon problème).

    Telle quelle, la situation ne me permet pas à Justin de modifier les droits d'un sous-dossier de "sono" de façon récursive (même s'il est propriétaire du sous-dossier en question), car la case "Appliquer à ce dossier, ces sous-dossiers, et ces fichiers" est désactivée (tout comme la possibilité de modifier le propriétaire ou le groupe auquel le sous dossier appartient).

    Si Justin appartient au groupe "administrators", la propagation dans les sous-dossiers devient possible.

    Voici les captures, d'abord pour Justin (la case est grisée), et ensuite pour Justin auquel j'ai donné des droits d'admin (la case est cliquable).

    droits_Justin.png

    droits_admin.png

    Est-ce là un comportement normal du DSM ? Car j'aimerais que mes utilisateurs puissent interdire aux autres l'accès des dossiers dont ils sont propriétaires, et donc il faudrait qu'ils puissent utiliser la récursivité. Je comprends que l'utilisateur ne puisse pas modifier le propriétaire ni le groupe, mais j'ai l'impression que la case de récursivité a été verouillée par la même occasion, certainement à tord.

    Merci de vos lumières.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.