Actions











Panne d'aujourd'hui...

Écrit le 07/10/2010 @ 13:19 par Drizzt

Site - Entretien/TweakSalut gang!

Désolé pour la panne entre 11h15 et 13h00. J'ai commencé à jouer sérieusement avec le pipes de ipfw. C'est du traffic shaping, c'est dans le but d'avoir une sorte de qualité de service, entre autres pour la téléphonie.

En gros, j'ai trouvé un bug dans MacOS X. Si je fais ipfw pipe flush ou ipfw pipe show, c'est presque certain que je plante le serveur Humm

J'ai envoyé mes bug-reports à Apple...

Le bon côté, c'est que ça semble fonctionner... je vais tester ce soir! Yeah!

Commentaire par Drizzt  Score: 2
Écrit le: 08/10/2010 @ 08:38

Le test d'hier avec Nick semblait concluant!

Je vais attendre un peu avant de crier victoire Smile

Commentaire par Drizzt  Score: 2
Écrit le: 09/10/2010 @ 16:41

Y'a une p'tite différence, mais ça va peut-être se corriger avec du fignolage (gestion du poid et du traffic...)

Commentaire par Drizzt  Score: 2
Écrit le: 12/10/2010 @ 14:12

Ma config, ce qui pourrait peut-être aider quelqu'un un jour...

# ipfw.conf.default - Installed by Apple, never modified by Server Admin app

#
# ipfw.conf - The servermgrd process (the back end of Server Admin app)
# creates this from ipfw.conf.default if it's absent, but does not modify it.
#
# Administrators can place custom ipfw rules in ipfw.conf.
#
# Whenever a change is made to the ipfw rules by the Server Admin application and saved:
# 1. All ipfw rules are flushed
# 2. The rules defined by the Server Admin app (stored as plists) are exported to
# /etc/ipfilter/ipfw.conf.apple and loaded into the firewall via ipfw.
# 3. The rules in /etc/ipfilter/ipfw.conf are loaded into the firewall via ipfw.
# Note that the rules loaded into the firewall are not applied unless the firewall is enabled.
#
# The rules resulting from the Server Admin app's IPFirewall and NAT panels are numbered:
# 1 - from serialnumberd - this rule is essential for serialnumberd and cannot be removed
# 10 - from the NAT Service - this is the NAT divert rule, present only
# when he NAT service is started via the Server Admin app.
# 1000 - from the "Advanced" panel - the modifiable rules, ordered by their
# relative position in the drag-sortable rule list
# 12300 - from the "General" panel - "allow"" rules that punch specific holes
# in the firewall for specific services
# 63200 - from the "Advanced" panel - the non-modifiable rules at the bottom
# of the panel's rule list
#
# Refer to the man page for ipfw(8) for more information.
#
# The following rules are already added by default:
#
#add 01000 allow all from any to any via lo0
#add 01010 deny all from any to 127.0.0.0/8
#add 01020 deny ip from 224.0.0.0/4 to any in
#add 01030 deny tcp from any to 224.0.0.0/4 in
#add 12300 ("allow" rules from the "General" panel)
#...
#add 65534 deny ip from any to any

del 10

# Notre traffic shaping
# http://lists.freebsd.org/pipermail/freebsd-net/2009-September/023173.html
pipe 1 config bw 110KBytes/sec
queue 1 config pipe 1 weight 100 queue 1KBytes
queue 2 config pipe 1 weight 4 queue 102KBytes gred 0.002/103/110/0.0001
queue 3 config pipe 1 weight 2 queue 102KBytes gred 0.002/103/110/0.001
queue 4 config pipe 1 weight 1 queue 102KBytes gred 0.002/103/110/0.01

#traffic prioritaire
# ATA VOIP
add 133 queue 1 ip from 192.168.1.55 to any out xmit en0
add 134 skipto 500 ip from 192.168.1.55 to any out xmit en0

#TCP ACK
add 135 queue 1 ip from any to any out via en0 tcpflags ack iplen 52 out xmit en0
add 136 skipto 500 ip from any to any out via en0 tcpflags ack iplen 52 out xmit en0

#Autres
add 152 queue 1 tcp from me to any 53 out xmit en0
add 153 skipto 500 tcp from me to any 53 out xmit en0
add 154 queue 1 udp from me to any 53 out xmit en0
add 155 skipto 500 udp from me to any 53 out xmit en0
add 156 queue 1 icmp from any to any out xmit en0
add 157 skipto 500 icmp from any to any out xmit en0
add 158 queue 1 tcp from me 22 to any out xmit en0
add 159 skipto 500 tcp from me 22 to any out xmit en0
add 160 queue 2 udp from any to any out xmit en0
add 161 skipto 500 udp from any to any out xmit en0
add 162 queue 2 tcp from any to any 80 out xmit en0
add 163 skipto 500 tcp from any to any 80 out xmit en0
add 164 queue 2 tcp from any to any 443 out xmit en0
add 165 skipto 500 tcp from any to any 443 out xmit en0

#traffic basse priorite

add 201 queue 3 tcp from any 80 to any out xmit en0
add 202 skipto 500 tcp from any 80 to any out xmit en0
add 203 queue 3 tcp from any 443 to any out xmit en0
add 204 skipto 500 tcp from any 443 to any out xmit en0
add 205 queue 3 tcp from any 5900 to any out xmit en0
add 206 skipto 500 tcp from any 5900 to any out xmit en0
add 207 queue 3 tcp from any 143 to any out xmit en0
add 208 skipto 500 tcp from any 143 to any out xmit en0
add 209 queue 3 tcp from any 993 to any out xmit en0
add 210 skipto 500 tcp from any 993 to any out xmit en0
add 211 queue 3 tcp from any 995 to any out xmit en0
add 212 skipto 500 tcp from any 995 to any out xmit en0
add 213 queue 3 tcp from any 8008 to any out xmit en0
add 214 skipto 500 tcp from any 8008 to any out xmit en0
add 215 queue 3 tcp from any 8843 to any out xmit en0
add 216 skipto 500 tcp from any 8843 to any out xmit en0
add 217 queue 3 tcp from any 110 to any out xmit en0
add 218 skipto 500 tcp from any 110 to any out xmit en0
add 219 queue 3 tcp from any 465 to any out xmit en0
add 220 skipto 500 tcp from any 465 to any out xmit en0
add 221 queue 3 tcp from any 587 to any out xmit en0
add 222 skipto 500 tcp from any 587 to any out xmit en0
add 301 queue 4 tcp from me to any out xmit en0
add 302 skipto 500 tcp from me to any out xmit en0
add 303 queue 4 tcp from any 6881-6999 to any out xmit en0
add 304 skipto 500 tcp from any 6881-6999 to any out xmit en0
add 305 queue 4 tcp from any to any 6881-6999 out xmit en0
add 306 skipto 500 tcp from any to any 6881-6999 out xmit en0

#traffic normal
add 331 queue 2 ip from any to any out xmit en0

add 500 divert natd ip from any to any via en0

add 65510 allow ipv6 from any to any


C'est le contenu de /etc/ipfilter/ipfw.conf
192.168.1.55 est mon ATA VoIP, qui doit avoir une absolue priorité
69.70.96.150 est mon IP public.

Update : Modification de la config, la nouvelle semble plus stable et protège mieux la téléphonie IP
Dernière modification le 09/11/2010 @ 09:59

Commentaire par Drizzt  Score: 2
Écrit le: 13/10/2010 @ 10:46

Ka m'a appelé au bureau ce matin, j'en ai profité pour tester moi-même la réception alors qu'elle me parlait. Ces lignes ont vraiment fait le travail et j'en suis TRÈS heureux Yeah!

Aucune coupure, le son était parfait... Enfin ça marche!

Commentaire par Drizzt  Score: 2
Écrit le: 19/10/2010 @ 11:45

Sauf que j'ai eu un crash pour une raison inconnue encore aujourd'hui Frown

Commentaire par Drizzt  Score: 1
Écrit le: 25/10/2010 @ 09:08

Encore hier soir Frown

Commentaire par Drizzt  Score: 2
Écrit le: 27/10/2010 @ 13:10

J'ai désactivé.. tanné d'avoir des plantages alléatoires. On va voir si c'était vraiment la cause en même temps...

Commentaire par Drizzt  Score: 2
Écrit le: 01/11/2010 @ 13:51

Je viens de réactiver. La carte vidéo d'origine semblait être en train de mourrir.. et là ça semble stable!

On verra ce que ça donne Wink

Commentaire par Drizzt  Score: 2
Écrit le: 01/11/2010 @ 14:38

Pas stable! Frown

On enlève encore!

Commentaire par Drizzt  Score: 2
Écrit le: 14/11/2010 @ 19:14

J'ai peut-être trouvé la source des instabilités, ça n'avait pas de lien avec le traffic shaping Frown

Commentaire par Drizzt  Score: 2
Écrit le: 15/11/2010 @ 12:27

J'ai retiré le disque Hitachi pour le remplacer par un WD neuf. Je suspectais le disque de ne pas bien fonctionner, il est donc en vérification au bureau.

Sinon, il va me rester un Seagate à remplacer par un WD, et je vais avoir un RAID plein de WD-Blue!

Commentaire par Drizzt  Score: 2
Écrit le: 18/11/2010 @ 08:56

On dirait que ça a rien changé Mad

Commentaire par Drizzt  Score: 2
Écrit le: 18/11/2010 @ 09:34

Fausse alerte. Un changement de config hier qui a causé la perte de réseautique. Ma douce a redémarré le serveur et tout est rentré dans l'ordre.

Commentaire par Drizzt  Score: 2
Écrit le: 18/02/2011 @ 13:18

Pour faire suite aux problèmes de stabilité...

Depuis quelques changements, le serveur tiens facilement plus d'une semaine sans problèmes. Il ne crash plus à proprement dit, mais après 1 semaine, l'USB ne fonctionnait plus ainsi que tous les périphériques. Il fallait un "hard-reset" du serveur pour rétablir la situation.

Après réflexion, je me suis souvenu, hier soir, que j'avais des problèmes avec mon hub USB avant. Il m'arrivait de perdre le scanner (périphérique branché dans le hub) ainsi que d'autres régulièrement sur mon iMac.

J'ai donc débranché le hub et rebranché tous les périphériques autrement....

On verra ce que ça donne! Sourire sans les dents

Commentaire par Drizzt  Score: 0
Écrit le: 21/02/2011 @ 07:28

Ça fait vraiment chier quand tu te rends compte que ton problème de stabilité depuis quelques mois est causé par une pièce de 15$ achetée il y a 2 ans...

Calvasse... le serveur va tellement bien maintenant Sourire sans les dents C'était vraiment une niaiserie...


Tous les blogs
<< clamAV : un antivirus pour tous, libre et performant | Retour aux blogs | Pourquoi je suis passé à Fedora et j'en suis revenu >>
Blogs de la même catégorie
<< Nouvelle section pour les utilisateurs VIP! | Panne de Vidéotron >>