Re-launch process [stunnel]

[xavierc]

Je constate régulièrement une notification de la part de mon TS-119 que mon process stunnel a été relancé. La notification est souhaitée mais pas l'anomalie

Server Name: xxxxxxxxxx

IP Address: xxxxxxxxxxx

Date/Time: 11/23/2009 22:10:09

Level: Warning

Re-launch process [stunnel].

J'ai la version 3.1.2 et j'accède la configuration de mon NAS via https uniquement.

J'ai créé un certificat privé que j'ai importé. J'ai essayé de le désinstaller et de le ré-installer mais cela n'évite pas ce message.

Je n'ai pas essayé de supprimer le certificat privé pour valider si mon certificat à un problème mais il me semble que j'avais déjà visualisé le problème avec la version 3.1.0 sans certififcat privé.

Je constate que j'ai ce message souvent lorsque je me connecte au TS-119 pendant qu'il travaille avec une certaine charge (genre pendant la sauvegarde vers mon disque externe connecté en eSata ou lors de copies de gros fichiers => CPU supérieur à 50%)

Je me rends compte de ce phènomène lors de mon accès à la page d'accueil et lorsque je souhaite accèder au module d'administration. Je n'y arrive pas et je dois relancer le chargement de la première page pour pouvoir cliquer à nouveau sur le module d'administration. Entre temps je reçois un message m'indiquant "Re-launch process [stunnel]"

Avez-vous déjà rencontré ce problème ?

Xavier

PS: j'ai aussi l'application Plugmedia sur mon TS-119

[xavierc]

Aucun rapport entre les deux problèmes sauf si ton idée se confirme que je dois ré-installer la version 3.1.2

Non ?

Xavier

[Xavier49]

[Qnap 212]

Bonjour,

J'ai voulu installer des certificats signés sur mon NAS accessible en administration uniquement en https.

Depuis j'ai des alertes email envoyées :

Re-launch process [stunnel]

Re-launch process [apache]

Re-launch process [proftpd]

Impossible de me connecter à nouveau, et donc de désinstaller ces nouveaux certificats qui ont l'air d'être non accepté par le serveur.

Quelqu'un connaîtrait-il les manipulations à faire en pour démarrer correctement apache et désinstaller les certificats ?

Merci pour votre aide.

[Demony]

Bon effectivement après quelques recherches sur le net, il ne faut pas utiliser les disques WesternDigital Caviar en RAID (merci Philippe pour le lien).

En plus les outils pour activer le TLER n'est pas compatible avec mes disques car ils sont trop récents.

Sinon, j'ai toujours le problème après avoir lancé les "balayage des blocs endommagés" sur mes disques. Il ne me reste plus qu'à faire une sauvegarde de mes données et à reformater mes disques pour ne plus les utiliser en RAID .

Mince, rue du commerce recommandait ces disques durs sur leur site quand j'ai commandé mon matériel et j'ai renvoyé un des disque en RMA à WesternDigital suite au problème (apres analyse par leur outils de diagnostique) donc c'est pas dit qu'il me les reprendrons sachant que celui que WD m'a retourné n'est pas celui que j'ai reçu par rueducommerce (c'est un remanufacturé).Description QNAP TS-419P+.

Encore Merci.

[father_mande]

Bonjour,

Merci Philippe.

Mon fichier stunnel est bien identique au tien (sauf en fonction de la config choisie bien sur).

J'ai fait un tar du répertoire /etc/config et /etc/default_config et malheureusement, certains fichiers ne sont pas bon.

Par exemple, le fichier crontab n'est pas clean, il y a des lignes en trop avec beaucoup de lignes vides et je ne parle même pas du fichier my.cnf.

Connais tu la manip pour faire un fsck de mon /dev/md9, connaissant les problèmes de filesystem montés et ne trouvant pas la commande fsck sur le NAS (ou peut être e2fsck mais c'est de l'ext3)?

Merci d'avance.

Contenu du fichier crontab.

[Global]

Available Disk = 1


<i>Beaucoup de lignes vide plus de 4000</i>


[Global]

Available Disk = 1

[VOLUME 1]

status = -1


<i>Beaucoup de lignes vide plus de 3000</i>


30 4 * * * /etc/init.d/Qthttpd.sh restart 1>>/dev/null 2>>/dev/null

0 4 * * * /sbin/hwclock -s

0 3 * * * /sbin/vs_refresh

0 3 * * 0 /etc/init.d/idmap.sh dump

0 12 * * 0 /sbin/qsmart -t short -d 1

0 12 * * 4 /sbin/qsmart -t extend -d 1

0 12 * * 0 /sbin/qsmart -t short -d 2

0 12 * * 4 /sbin/qsmart -t extend -d 2

0 12 * * 0 /sbin/qsmart -t short -d 3

0 12 * * 4 /sbin/qsmart -t extend -d 3

0 12 * * 0 /sbin/qsmart -t short -d 4

0 12 * * 4 /sbin/qsmart -t extend -d 4

0 1 * * 6 /etc/init.d/poweroff

0 7 * * 6 /etc/init.d/startup

0 3 * * * /etc/init.d/ImRd.sh bgThGen

38 * * * * /sbin/qddns_check 2>/dev/null


<i>pour un total de 7048 lignes</i>

Vous avez un bouton "balayage des blocs endommagés" dans la gestion du volume ... qui fait cela très bien ...

Sinon, je viens de voir votre message d’accueil ... et vous semblez bien être "tombé" dans le piège de WD green en Raid ...

Vérifiez que vos disques sont dans la liste de compatibilité et si non, demandez à votre revendeur de les remplacer ...

http://www.qnap.com/...mpatibility.asp

Philippe.

[Demony]

Merci Philippe.

Mon fichier stunnel est bien identique au tien (sauf en fonction de la config choisie bien sur).

J'ai fait un tar du répertoire /etc/config et /etc/default_config et malheureusement, certains fichiers ne sont pas bon.

Par exemple, le fichier crontab n'est pas clean, il y a des lignes en trop avec beaucoup de lignes vides et je ne parle même pas du fichier my.cnf.

Connais tu la manip pour faire un fsck de mon /dev/md9, connaissant les problèmes de filesystem montés et ne trouvant pas la commande fsck sur le NAS (ou peut être e2fsck mais c'est de l'ext3)?

Merci d'avance.

Contenu du fichier crontab.

[Global]

Available Disk = 1


<i>Beaucoup de lignes vide plus de 4000</i>


[Global]

Available Disk = 1

[VOLUME 1]

status = -1


<i>Beaucoup de lignes vide plus de 3000</i>


30 4 * * * /etc/init.d/Qthttpd.sh restart 1>>/dev/null 2>>/dev/null

0 4 * * * /sbin/hwclock -s

0 3 * * * /sbin/vs_refresh

0 3 * * 0 /etc/init.d/idmap.sh dump

0 12 * * 0 /sbin/qsmart -t short -d 1

0 12 * * 4 /sbin/qsmart -t extend -d 1

0 12 * * 0 /sbin/qsmart -t short -d 2

0 12 * * 4 /sbin/qsmart -t extend -d 2

0 12 * * 0 /sbin/qsmart -t short -d 3

0 12 * * 4 /sbin/qsmart -t extend -d 3

0 12 * * 0 /sbin/qsmart -t short -d 4

0 12 * * 4 /sbin/qsmart -t extend -d 4

0 1 * * 6 /etc/init.d/poweroff

0 7 * * 6 /etc/init.d/startup

0 3 * * * /etc/init.d/ImRd.sh bgThGen

38 * * * * /sbin/qddns_check 2>/dev/null


<i>pour un total de 7048 lignes</i>

[father_mande]

Bonjour,

Bonjour,

Suite à un problème avec un de mes disques dur en RAID5, beaucoup de lignes du format suivant apparaissaient toutes les 30 secondes dans les logs.

2011-06-10 23:04:40 System 127.0.0.1 localhost Re-launch process [stunnel].

J'ai modifié le fichier /etc/init.d/stunnel.ksh pour pouvoir router les logs dans des fichiers distincts:

/sbin/daemon_mgr stunnel start \

"/usr/sbin/stunnel /etc/stunnel/stunnel.conf 2>>/share/Public/errorstunnel.log 1>>/share/Public/stdoutstunnel.log"

Après analyse des logs, on peut s'apercevoir que des messages d'erreur apparaissaient.

"line 2: Specified option name is not valid here"

Pour résoudre le problème, suivre les instructions suivantes:

Aller dans l'interface de gestion et décocher la case "Activer la connexion ssl" dans Administration du système et réglages de base, puis appliquer les changements.

Se connecter en [url="[url="[url="ssh-avec-putty/-avec-putty/"]ssh-avec-putty/-avec-putty/"][url="ssh-avec-putty/-avec-putty/"]ssh-avec-putty/-avec-putty/"][url="[url="ssh-avec-putty/-avec-putty/"]ssh-avec-putty/-avec-putty/"][url="ssh-avec-putty/-avec-putty/"]ssh-avec-putty/ sur le serveur NAS (utilisation de putty).

Faire une copie de sauvegarde du fichier /etc/stunnel/stunnel.conf qui pose problème au cas où.

cp -p /etc/stunnel/stunnel.conf /etc/stunnel/stunnel.conf.backup

Restaurer le fichier stunnel.conf à partir de celui qui se trouve dans /etc/default_config/stunnel

cp /etc/default_config/stunnel/stunnel.conf /etc/stunnel/stunnel.conf

Editer le fichier ainsi copier avec vi et modifier la ligne "accept" dans la section [https] pour mettre le port d'écoute de votre choix (de préférence, le même que dans l'interface de gestion).

vi /etc/stunnel/stunnel.conf (faire la modification puis faire appuyer sur la touche "echap" puis ":" puis "x" pour enregistrer les modifs. Sinon faire "ECHAP" ":" "q" "!" pour quitter sans enregistrer.

[https]

accept = 443

connect = 127.0.0.1:8080

Aller dans l'interface d'administration et cocher la case "Activer la connexion ssl" et appliquer les changements.

Cela devrait résoudre le problème.

D'ailleurs, si quelqu'un pouvait me copier le contenu de son fichier ce serait super que je puisse comparer.

Maintenant, reste à savoir ce qui s'est passé.

Extrait du fichier de config avant et après.

A priori, votre erreur disque a été aussi, sur le Raid1 (/dev/md9) qui contient HDA_ROOT et le répertoire config (.config lié a /etc/config)

... car c'est le fichier uLinux.conf qui est venu écraser le fichier stunnel.conf ....

faites d'urgence un check des disques ... (et des backup des données si ce n'est dèjà fait)

mon fichier stunnel.conf , même si je n'utilise pas stunnel pour sécuriser mes connexions ...

[~] # cat /etc/stunnel/stunnel.conf

; Sample stunnel configuration file by Michal Trojnara 2002-2006

; Some options used here may not be adequate for your particular configuration

; Please make sure you understand them (especially the effect of chroot jail)


; Certificate/key is needed in server mode and optional in client mode

cert = /etc/stunnel/stunnel.pem

;key = /usr/local/etc/stunnel/mail.pem


ciphers = ALL:!SSLv2:!LOW:!EXPORT40:@STRENGTH

;chroot = /usr/local/var/lib/stunnel/

setuid = admin

setgid = administrators

; PID is created inside chroot jail

pid = /stunnel.pid


; Some performance tunings

socket = l:TCP_NODELAY=1

socket = r:TCP_NODELAY=1

;compression = rle


; Workaround for Eudora bug

;options = DONT_INSERT_EMPTY_FRAGMENTS


; Authentication stuff

;verify = 2

; Don't forget to c_rehash CApath

; CApath is located inside chroot jail

;CApath = /certs

; It's often easier to use CAfile

;CAfile = /usr/local/etc/stunnel/certs.pem

; Don't forget to c_rehash CRLpath

; CRLpath is located inside chroot jail

;CRLpath = /crls

; Alternatively you can use CRLfile

;CRLfile = /usr/local/etc/stunnel/crls.pem


; Some debugging stuff useful for troubleshooting

debug = 7

output = /dev/null


; Use it for client mode

client = no


; Service-level configuration


;[pop3s]

;accept  = 995

;connect = 110


;[imaps]

;accept  = 993

;connect = 143


;[ssmtp]

;accept  = 465

;connect = 25


[https]

accept = 443

connect = 127.0.0.1:8077

TIMEOUTclose = 0


; vim:ft=dosini

[~] #

Philippe.

[Demony]

Bonjour,

Suite à un problème avec un de mes disques dur en RAID5, beaucoup de lignes du format suivant apparaissaient toutes les 30 secondes dans les logs.

2011-06-10 23:04:40 System 127.0.0.1 localhost Re-launch process [stunnel].

J'ai modifié le fichier /etc/init.d/stunnel.ksh pour pouvoir router les logs dans des fichiers distincts:

/sbin/daemon_mgr stunnel start \

"/usr/sbin/stunnel /etc/stunnel/stunnel.conf 2>>/share/Public/errorstunnel.log 1>>/share/Public/stdoutstunnel.log"

Après analyse des logs, on peut s'apercevoir que des messages d'erreur apparaissaient.

"line 2: Specified option name is not valid here"

Pour résoudre le problème, suivre les instructions suivantes:

Aller dans l'interface de gestion et décocher la case "Activer la connexion ssl" dans Administration du système et réglages de base, puis appliquer les changements.

Se connecter en sur le serveur NAS (utilisation de putty).

Faire une copie de sauvegarde du fichier /etc/stunnel/stunnel.conf qui pose problème au cas où.

cp -p /etc/stunnel/stunnel.conf /etc/stunnel/stunnel.conf.backup

Restaurer le fichier stunnel.conf à partir de celui qui se trouve dans /etc/default_config/stunnel

cp /etc/default_config/stunnel/stunnel.conf /etc/stunnel/stunnel.conf

Editer le fichier ainsi copié avec vi et modifier la ligne "accept" dans la section [https] pour mettre le port d'écoute de votre choix (de préférence, le même que dans l'interface de gestion).

vi /etc/stunnel/stunnel.conf (faire la modification puis faire appuyer sur la touche "echap" puis ":" puis "x" pour enregistrer les modifs. Sinon faire "ECHAP" ":" "q" "!" pour quitter sans enregistrer.

[https]

accept = 443

connect = 127.0.0.1:8080

Aller dans l'interface d'administration et cocher la case "Activer la connexion ssl" et appliquer les changements.

Cela devrait résoudre le problème.

D'ailleurs, si quelqu'un pouvait me copier le contenu de son fichier ce serait super que je puisse comparer.

Maintenant, reste à savoir ce qui s'est passé.

Extrait du fichier de config avant et après.

[system]

Model = TS-419P

Internal Model = TS-419

Server comment = NAS Server

Version = 3.4.2

Build Number = 0331T

Time Zone = Europe/Paris

Enable Daylight Saving Time = TRUE

Workgroup = NAS

Code Page = 850

System Device = /dev/sdx

Test Mode = FALSE

Auto Create Raid = raid0

Wan Access = TRUE

Lan Access = TRUE

Web Access Port = 8080

E2KEY Support = FALSE

Rsync Support = TRUE

Rsync Model = QNAP

FS Type = ext3

Auto PowerOn = TRUE

Quota Type = vfsv0

Write Connection Log = 1

Enable Live Update = TRUE

Live Update XML = http://update.qnap.com/FirmwareRelease.xml

Booting = 0

Server Name = QNAP419P

UPNP_UUID = XXXXXXXXX-XXXX-XXXX-XXXX-YYYYYYYYYYYY

Date Format Index = 1

Password constraints = 0

Force SSL = 0

[Test]

Test Program = /sbin/test/Self-test-main

[NTP]

USE NTP Server = TRUE

NTP Server IP = pool.ntp.org

Enable NTP Server = FALSE

Server1 IP =

Server2 IP =

Sercer3 IP =

Interval = 1

TimeUnit = HOUR

[Alert]

Alert Level = 2

SMTP IP = 0.0.0.0

Alert Mail = nobody@domain.com,

SMS Mode = 0

Sender = nobody@domain.com

[Network]

Interface Number = 2

DNS = 0.0.0.0

WINS IP = 0.0.0.0

WINS Enable = False

BONDING Support = False

BONDING01 = Interface1

BONDING02 = Interface2

Domain Name Server 1 = 212.27.40.241

Domain Name Server 2 = 212.27.40.240

DNS type = manual

Default GW Device = eth0

IP Security = 3

[bond0]

Bonding Mode = 1

Configure = False

Use DHCP = TRUE

Usage = DHCP

IP Address = XXX.XXX.100.100

Subnet Mask = [https]

accept = 8443

[https]

accept = 8443

; Sample stunnel configuration file by Michal Trojnara 2002-2006

; Some options used here may not be adequate for your particular configuration

; Please make sure you understand them (especially the effect of chroot jail)

; Certificate/key is needed in server mode and optional in client mode

cert = /etc/stunnel/stunnel.pem

;key = /usr/local/etc/stunnel/mail.pem

ciphers = ALL:!SSLv2:!LOW:!EXPORT40:@STRENGTH

;chroot = /usr/local/var/lib/stunnel/

setuid = admin

setgid = administrators

; PID is created inside chroot jail

pid = /stunnel.pid

; Some performance tunings

socket = l:TCP_NODELAY=1

socket = r:TCP_NODELAY=1

;compression = rle

; Workaround for Eudora bug

;options = DONT_INSERT_EMPTY_FRAGMENTS

; Authentication stuff

;verify = 2

; Don't forget to c_rehash CApath

; CApath is located inside chroot jail

;CApath = /certs

; It's often easier to use CAfile

;CAfile = /usr/local/etc/stunnel/certs.pem

; Don't forget to c_rehash CRLpath

; CRLpath is located inside chroot jail

;CRLpath = /crls

; Alternatively you can use CRLfile

;CRLfile = /usr/local/etc/stunnel/crls.pem

; Some debugging stuff useful for troubleshooting

debug = 7

output = /dev/null

; Use it for client mode

client = no

; Service-level configuration

;[pop3s]

;accept = 995

;connect = 110

;[imaps]

;accept = 993

;connect = 143

;[ssmtp]

;accept = 465

;connect = 25

[https]

accept = 8443

connect = 127.0.0.1:8080

TIMEOUTclose = 0

[wfm]

accept = 8090

connect = 127.0.0.1:8008

TIMEOUTclose = 0

; vim:ft=dosini

[father_mande]

J'ai la version 3.1.2 et j'accède la configuration de mon NAS via https uniquement.

J'ai créé un certificat privé que j'ai importé. J'ai essayé de le désinstaller et de le ré-installer mais cela n'évite pas ce message.

Je n'ai pas essayé de supprimer le certificat privé pour valider si mon certificat à un problème mais il me semble que j'avais déjà visualisé le problème avec la version 3.1.0 sans certififcat privé.

Je constate que j'ai ce message souvent lorsque je me connecte au TS-119 pendant qu'il travaille avec une certaine charge (genre pendant la sauvegarde vers mon disque externe connecté en eSata ou lors de copies de gros fichiers => CPU supérieur à 50%)

Je me rends compte de ce phènomène lors de mon accès à la page d'accueil et lorsque je souhaite accèder au module d'administration. Je n'y arrive pas et je dois relancer le chargement de la première page pour pouvoir cliquer à nouveau sur le module d'administration. Entre temps je reçois un message m'indiquant "Re-launch process [stunnel]"

Avez-vous déjà rencontré ce problème ?

Xavier

PS: j'ai aussi l'application Plugmedia sur mon TS-119

Bonjour,

A priori plugmedia n'a rien a voir avec stunnel ...

En 3.2.1 les connexions ssl sont gérés de deux façons

1) le port 443 pour l'administration via stunnel

2) un port (8081) pour le ssl des Web serveur

Stunnel ne gère que la connexion administration

Vous pouvez : modifier le fichier /etc/config.stunnel.conf pour changer l'output du debug qui est : /dev/null par un path vers un fichier ... cela permettra éventuellement d'avoir une idée du probléme.

Sur le Forum Anglais, d'autres semblent avoir eu un probléme identique, reglé (TBC) en revenant au certificat original ...

vérifier vos certificats ils sont aussi dans /etc/config/stunnel ...

Ne travaillant pas avec ssl (mais avec des tunnels ssh) pour l'administration, je n'ai pas d'expérience sur le sujet.

Philippe.

[xavierc]

Pour information, j'ai ouvert un call officiel sur le site QNAP car je continue à rencontrer des problèmes 1 loggon sur 2 en https...

Xavier

[xavierc]

Après une ré-installation de mon TS119 avec la version 3.1.2, mon MediaServeur re-fonctionne. Ouf !

Je vais vérifier si je trouve à nouveau des messages Re-Launch après cette action

Merci pour ton idée Cris

Xavier

[cris]

cad un rapport?

[xavierc]

Je vais effectivement essayer d'appliquer à nouveau le Firmware 3.1.2.

J'ai constaté une autre anomalie, j'ai mon MediaServer qui fonctionne mais le NMP trouve aucun fichier, comme la XBOX 360 et aussi la PS3.

J'ai pas trouvé après multiples recherches.

Je vais tenter ton approche.

Xavier

PS:

Mon problème est décrit exactement par un autre utilisateur sur le forum anglais. Et pas vraiment de réponse ...

http://forum.qnap.com/viewtopic.php?f=160&t=19174

pour rappel dans la version 3.1.2 (un rapport avec AES-256 ?)

[Version & Build]

v3.1.2 Build1014

[Enhancement]

- Disable NCQ to improve the RAID stability with some Western Digital hard drives (WD20EADS, WD15EADS, WD10EADS, WD2002FYPS, WD1002FBYS)

- Provide Enhanced AES-256 encryption in data security. The update is backward compatible and does not require any additional modification by user.

[bugfix]

- With multiple volumes, the free volume size was incorrect when creating an iSCSI Target on volumes other than the 1st one

- Fix Finder can't connect to NAS normally in some situations

- Fix Pacific?Mountain?Central?and Eastern time zone settings that cannot be applied and overwritten.

- Update the time zone of Auckland, New Zealand

[comicway]

humm je pense pas que safari puisse planter le processus.

Est ce que tu sais reinstaller le firmware?

[xavierc]

Constat après avoir remis le certificat par défaut quelques heures après:

une connexion en https sur 3 donne lieu à une anomalie Re-launch process [stunnel]. Et cette fois-ci je fais le constat sans activité exceptionnelle sur le NAS.

Je n'ai pas redémarré le NAS depuis ce changement.

Constat normal ou anormal ?

En fait, qu'est-ce qui ce passe : le process stunnel est (re)démarré car il n'est pas actif au moment de l'appel de la fonction ou il est planté et lors de l'appel à la fonction il le redémarre ?

Est-il possible que mon browser Safari 4 soit responsable de ce crash ? J'ai pas essayé avec Firefox 3.5...

Xavier

[xavierc]

J'ai restauré le certificat par défaut.

Je te tiendrais informé si je constate à nouveau des warnings lorsque je me connecte en https.

Merci pour ton aide

Xavier

[cris]

Essaie:

restaurer le certificat par défaut

[xavierc]

Peux-tu être plus précis:

J'ai "restauré le certificat par défaut" dans la console d'administration "Importer un certificat SSL de sécurité" et le statut me précise le changement.

Cela est-il suffisant ?

Si j'ai un problème de certificat pourquoi cela marche t-il sans problème et que quelque fois j'ai l'anomalie lors d'une connexion ?

Mon certificat n'est pas signé par une société externe (comme verisign par exemple) par conséquent je peux aussi le supprimer si cela pose trop de problème. Cela ne m'empêchera pas de me connecter en SSL.

Xavier

[cris]

C'est du a un probleme de certificat.

Est ce que tous les certificats ont été enlevés?