LaBienPensanceMaTuer a écrit 1611 commentaires

Après vérification:
mailbox_size_limit (default: 51200000)

The maximal size of any local(8) individual mailbox or maildir file, or zero (no limit). In fact, this limits the size of any file that is written to upon local delivery, including files written by external commands that are executed by the local(8) delivery agent.

This limit must not be smaller than the message size limit.

Donc ton problème je pense vient bien de ce paramètre ...

[gco@gc]:~% echo "51200000/(1024^2)" |bc
48

On est pas trop trop loin des 45Mo ...

Et bien test à la main....
Soit tu attend qu'il ai atteint ce seuil des 45Mo et tu tentes de faire un cat mail | procmail en tant que lui pour voir ce que te dit exactement le système.
Ou sinon, tu stoppes le postfix quelques instants, tu fais un:


mv /var/spool/mail/user{,.old}
su - user
dd if=/dev/zero of=/var/spool/mail/user bs=1k count=45000
cat /etc/passwd >> /var/spool/mail/user


Manifestement, cela ressemblerai à un problème de quota ...
ou un problème d'espace disque: un df te rapporte de l'espace disque dispo ?

Une autre solution ...:

[root@gc]:/home/gco# postconf -d |grep mailbox_size
mailbox_size_limit = 51200000


N'aurait il pas atteint la taille maximale autorisée par postfix ? (cela me semblerait étrange tout de même vu que tu passes par procmail pour la delivery).

Yep en gros c'est ça. J'ai préféré utiliser squid, car, tant qu'à faire autant utiliser les fonctionnalités de cache.

En gros les directives à modifier dans la conf de squid sont:

http_port 127.0.0.1:3128

acl localhost src 127.0.0.1/255.255.255.255
http_access allow localhost

Et c'est réglé pour le squid.

Pour ce qui est du tunnel ssh:

ssh -L 3128:localhost:3128 <box>


ou encore ajouter la section suivante:

Host <box>
LocalForward 3128 127.0.0.1:3128


Dans ton ~/.ssh/config

C'est à pisser de rire ... ça me rappelle quand j'avais 16 ans et que j'ai découvert l'ezine NoWay en même temps que le punk ...


encore une cyberdatakulturelle que 2brank et l'autre gonzo-bidouilleur
n'ont pas encore downloadée dans leur brain de dandy-mongolz
post 80's :

RAS LE BOL DES IEUVS DE L'INFO
RAS LE BOL DES JOURNALEUX MULTICASQUETTES A LA RAM4$$
RAS LE BOL DE MA MEDIOCRITé DE LA HiiiiiPE DOMINANTE
FUCK THEM ALL!
TAKE NO PRISONNERS
MEDIA NOSTRA EN FORCE

C'est un slogan ? une blague ? un poème ?


je pogote avec eux en face
du barc ourcq l'été/

C'est cool ! C'est trop hiiiipe même je dirai !


(muni d'un allume gaz electrik dessossé tu fous des
étincelles sur la plak de la fente et tu chopes des parties gratuites)

So "hack" spirit ...

Maintenant eventuellement, si tu pouvais nous expliquer en virant les passages inutiles (ce qui devrait ramener ton journal à douzaine de lignes) et le barratin de rebelz num3r1k (hop plus que 3 lignes), ce qu'il y a d'intéressant et ou !

ps : c'est pas pour cacher un surf à mon employeur, c'est moi mon employeur


Bein moi, perso, pour cacher mes surfs à mon employeur (je n'ai rien à cacher dans le fond, c'est simplement par principe), j'utilise la solution du proxy Squid distant qui écoute seulement sur le loopback couplé à un tunnel SSH.
Pour de la consultation web toute bête, c'est excellent. Après, si tu aimes jouer au gros jeu en flash et que la machine distante à une bande passante en upload réduite, tu risques de sentir les limites de cette solution, mais bon.

J'crois avoir un éventail assez "intéressant" (khof) sur l'un des sites que j'héberge:

herotisme 55 6.9 %
hemoroide 32 4 %
hérotisme 10 1.2 %
jean pierre pernaud 8 1 %
probleme gastrique 3 0.3 %
ducruet pernaud 3 0.3 %
niqueuse 3 0.3 %
nain porno 2 0.2 %
herotisme asiatique 2 0.2 %
cul avec un nain 2 0.2 %
porno nain 2 0.2 %
123 salope 2 0.2 %
nikos alliagas 2 0.2 %
pucelles anal 1 0.1 %
vaches en chaleur 1 0.1 %
porno asiatique 1 0.1 %
vas y sa vient 1 0.1 %
pernaud cocu? 1 0.1 %
sodomiser par son voisin 1 0.1 %

A croire quand même que la nouvelle tendance sexuelle est résolument orienté personnes de petite taille...

Je tiens à préciser que, malgré ce que l'on pourrait croire, ce site n'a pas un contenu "adulte" :) Simplement que l'ami google parse aussi les flux RSS.

Il a raison le monsieur, j'voulais te répondre comme lui, mais bon, t'avais l'air tellement sur de toi ...
Ce message dans les logs est CARACTERISTIQUE ! C'est bien le droit d'outrepasser les "Options" qu'il te manque.

En fait, il faut que tu autorises les modifications de la conf PHP via les .htaccess pour ce répertoire.

En gros, il s'agit de la directive AllowOverride dans ton httpd.conf

Exemple:

<Directory /home/webusers>
AllowOverride Options
</Directory>

Cf la doc: http://www.nexen.net/docs/php/annotee/configuration.changes.apache.php

je crois pas que tu sois sur le bon site ... en effet, je pense que la majorité des utilisateurs de ce site on peu/pas de connaissances windows et encore moins de connaissances IIS.

Pour la solution apache en reverse proxy, je ne saurai que trop de la conseiller ... en effet, ça te permettra de coupler apache à mod_security et de pouvoir filtrer les vilaines failles touchant IIS, telles que la dernière en date triviale exploiter comme à protéger:

http://ingehenriksen.blogspot.com/2005/12/microsoft-iis-remo(...)

Euh en fait j'ai dit n'importe quoi.
Suis complétement confus :/
Moinssez vite histoire de cacher ces conneries.

Salut, ton erreur est assez classique.
En fait tu fais un:

adresse.sin_addr.s_addr = inet_addr("192.168.0.190");

adresse.sin_addr.s_addr est selon ip(7) un u_int32_t appartenant à une structure de type in_addr.

La fonction inet_addr(3) quant à elle renvoie directement une structure de type in_addr.
L'assignation correcte serait donc:

adresse.sin_addr = inet_addr("192.168.0.190");

As tu pensé au flag -Wall de gcc qui t'aurait certainement montré cette erreur ?

Et la tu es entré dans le plus gros troll qui existe entre Linuxiens et BSDiste: leurs notions respectives de la liberté.
Tu ne peux pas forcer un développeur à placer son code, même si il s'agit du cas bien particulier d'un driver, sous une licence X ou Y.

Avec un joli message comme il l'a eu:

Power button pressed


Inutile de débrancher le bouton (mieux vaux meme l'avoir branché, quand il s'agit d'allumer la machine :p).
Par contre, une petite retouche au niveau ACPI aurait fait l'affaire.
Exemple sous ma Debian:

[binarym@trait-plat]:/etc/acpi% cat powerbtn.sh
#!/bin/sh

if ps -Af | grep -q '[k]desktop' && test -f /usr/bin/dcop
then
dcop --all-sessions --all-users ksmserver ksmserver logout 0 2 0 && exit 0
else
/sbin/shutdown -h now "Power button pressed"
fi

[binarym@trait-plat]:/etc/acpi% cat events/powerbtn
# /etc/acpi/events/powerbtn
# This is called when the user presses the power button
event=button[ /]power
action=/etc/acpi/powerbtn.sh

En gros, il te suffirait donc de remplacer /etc/acpi/powerbtn.sh par un ptit /etc/acpi/boite_a_baffe_usb.sh :p

Unscaled

By default each graph is scaled vertically to make the actual data visible even when it is much lower than MaxBytes. With the Unscaled variable you can sup-
press this. It's argument is a string, containing one letter for each graph you don't want to be scaled: d=day w=week m=month y=year. There is also a special
case to unset the variable completely: n=none. This could be useful in the event you need to override a global configuration. In the example scaling for the
yearly and the monthly graph are suppressed.

Example:

Unscaled[ezwf]: ym

J'ai eu ce soucis également avec une passerelle sous Debian.

Il s'agissait d'un problème de MTU: En gros, ma route par défaut était sur un lien ppp, donc MTU de 1492, et mon LAN quant à lui avait le MTU par défaut de 1500. Visiblement, ça ne plait pas beaucoup à la pile réseau.

J'ai résolu ce problème en indiquant à mes clients sous linux d'utiliser le MTU fourni par le serveur DHCP.

Donc, dans le fichier /etc/dhcpd.conf côté gateway:
option interface-mtu 1492;

Dans le fichier /etc/dhclient.conf:

request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name, interface-mtu;

Et c'est réglé.
Les références qui m'ont éclairés dans la résolution du problème:

http://lists.debian.org/debian-devel/2005/10/msg00377.html http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309205

Pour ne pas faire de linuxfr un vulgaire site de petites annonces, je vais poster la mienne en commentaire de celle ci:

Donc je vend la machine qui me servait de gate pour cause de renouvellement, la description détaillée est ici:

http://psycho-hazard.net/~binarym/?what=pages/achetez

Pour du monitoring, t'as plusieurs solutions qui existent:

_ mon - http://www.kernel.org/software/mon/ - Rudimentaire mais plutot léger.

_ nagios - http://www.nagios.org/ - Excessivement complet mais plutôt lourd.

Ca depend deja de ta distribution...
Dans ton cas de figure (boot ala SystemV),
Le rcX.d à utiliser dépend du runlevel (man init et inittab pour plus de détails).

Généralement, tu n'as pas à t'embêter toi même avec ces liens, ta distribution doit incorporer un outil gérant tout ça.
Sous Debian par exemple, c'est le script /usr/sbin/update-rc.d qui se charge de ça.

Donc en gros tu crées le script kivabien(c) dans ton /etc/init.d et tu appelles ensuite le tool kivabien(c) en te contentant je pense des valeurs par défaut (update-rc.d script defaults sous debian)

moi j'dis que ça passera pas.

On en a parlé sur linuxfr ainsi que sur les ml Debian, mais visiblement tu as besoin d'une piqure de rappel:

http://www.eyrolles.com/Informatique/Livre/9782212116397/

Sinon je confirme cette une idée particulièrement mauvaise que de débuter sur de la sid !

Hmm non en fait.

En gros à l'instar de Windows 98 qui a été le windows stable(ahah) en 1998, la Debian Woody est la debian stable d'il y a quelques années.

A l'instar de Windows XP venu remplacer Windows 98, Sarge est la nouvelle stable de chez Debian.

Donc la woody comme la sarge sont très stables, toutefois, la woody est complétement obsolète.

Avant d'être stable, la Sarge se nommait Sarge aussi mais était la branche testing. Une fois que l'ensemble Sarge est devenu parfaitement "cohérent", les développeurs Debian ont choisis de freezer la distribution et d'en faire la nouvelle stable.

Sid quant à elle sera toujours la version unstable.
En espérant avoir été suffisamment clair...

ethereal peut exploiter des dumps au format pcap.
Donc utilise tcpdump -w out.pcap sur le serveur puis récupère le fichier en question pour le réexploiter avec ethereal.

Et à la limite si tu veux du temps réel, tu devrais pouvoir t'en sortir avec netcat et mkfifo.

C'est complétement logique, et tu ne pourras pas avoir d'autre comportement.
Effectivement, lorsque tu dis à ton navigateur de te connecter en SSL à un site, la première chose que ce dernier va faire est négocier le chiffrement, or le squid/c'quetuveux de ta boite ne cause que l'HTTP, donc il va pas être fichu de répondre au "handshake SSL".

En temps normal, le HTTPS over proxy se passe de la façon suivante:

1/ Le navigateur se connecte au proxy et utilise la méthode HTTP Connect pour demander à être connecté au site https://chose.com

2/ Le proxy accepte et ouvre un bête tunnel entre chose.com:443 et ta machine

3/ Ton navigateur débute alors la négociation SSL puis la navigation en elle même via ce tunnel.

Si tu réfléchis deux secondes au proto HTTPS, tu te rendras rapidement compte qu'il n'y a pas de possibilité de faire du proxying HTTPS transparent à cause des mecanismes de chiffrement asymétriques.

Apprends à poser des questions, qu'est ce que tu veux avoir comme réponse avec une question formulée ainsi ?

Il nous faudrait:

dmesg |grep eth

lsmod

ifconfig -a

cat /etc/network/interfaces

Sans "infos", les seules réponses que je peux te donner sont:

1/ Rebranche le cable.
2/ Installe une mandrake.
3/ Laisse tomber le réseau internet ça sert à rien.

Que puis je faire ?

Regarder les fichiers de logs de dovecot par exemple ?
Puis chercher sur google le message d'erreur que tu y trouveras, ou lire la page de man ou meme, en dernier lieu, nous paster ici un extrait (et non l'intégralité) significatif du fichier de log en question.