#0 Re : -1 » [Résolu]VirtualHost - Apache » Le 21/05/2008, à 21:54
- Thamior
- Réponses : 3
Salut,
alors, à rajouter dans ton httpd.conf par exemple :
NameVirtualHost 192.168.1.10:80
NameVirtualHost 192.168.1.10:443
puis modifier le fichier hosts :
127.0.0.1 localhost
192.168.1.10 le_nom_de_ton_serveur
site1.no-ip.org et site2.no-ip.org étant déclaré dans les DNS, inutile de les rajouter dans le hosts.
#1 Re : -1 » [RESOLUT!!!!!]MAJ Dinamyque Bind9 et dhcp » Le 24/06/2008, à 12:42
- Thamior
- Réponses : 31
as tu autorisé ton localhost (127.0.0.1) dans la directive "allow-update" de ta zone ?
allow-update { 127.0.0.1; };
#2 Re : -1 » [RESOLUT!!!!!]MAJ Dinamyque Bind9 et dhcp » Le 24/06/2008, à 16:49
- Thamior
- Réponses : 31
Sa deuxième solution (déclaré la même clé dans le fichier dhcpd.conf) est bonne aussi. Et évite de modifier les groupes.
Par contre, il y a des erreurs de config :
* La zone et le reverse sont déclaré 2 fois dans dhcpd.conf, une fois avec la prise en compte de la key, et l'autre sans....
* Allow-transfert n'a pas a être déclaré ici, surtout pour y mettre un 127.0.0.1 (ce qui signifierai que le primaire transfert ses zones à lui même Oo).
* notify n'a rien a faire là si pas de DNS secondaires (même principe que Allow-transfert).
* Je ne comprends les directives forwarders{} vident.. Si tu veux décharger ton serveur de la résolution des zones qui ne t'appartiennent pas (le web), déclare alors cette directive dans ton "named.conf.options" par exemple (ici pour Free) :
forwarders {
212.27.54.252;
212.27.53.252;
};
et du même coup, commente les serveurs racines (ils seront content ^^) :
//zone "." {
// type hint;
// file "/etc/bind/db.root";
//};
#3 Re : -1 » [RESOLUT!!!!!]MAJ Dinamyque Bind9 et dhcp » Le 24/06/2008, à 20:31
- Thamior
- Réponses : 31
C'est normal, çà ne change rien de tout à l'heure. Mets plutot la config de ta clé directement dans le fichier dhcpd.conf.
Ex :
key "rndc-key" {
algorithm hmac-md5;
secret "XXXXXXXXXXXXXXXXXXX";
};
Poste aussi ton named.conf.options.
Redémarre ton service DHCP. Si çà ne fonctionne pas, donne nous les logs NAMED et DHCPD
#4 Re : -1 » Problème Nagios et Postfix » Le 23/06/2008, à 11:03
- Thamior
- Réponses : 22
Salut,
admin_email n'est qu'un export de variable mais n'est pas utilisé par Nagios, sauf si on l'intègre dans un script.
Dans Nagios, tu as déclaré tes hosts à "checker", logiquement dans le fichier /etc/nagios/hosts.cfg.
Dans un fichier /etc/nagios/contacts.cfg, tu déclares tes destinataires ainsi que les groupes qui seront notifiés en cas de pépin.
La déclaration prend cette forme :
define contact {
contact_name toto
alias contact toto
host_notification_period 24x7
service_notification_period 24x7
host_notification_options d,u,r
service_notification_options w,u,c,r
host_notification_commands host-notify-by-email
service_notification_commands notify-by-email
email toto@toto.fr
}
et les groupes :
define contactgroup {
contactgroup_name admins
alias Les Geeks
members toto
}
Tu peux déjà commencer par vérifier çà
#5 Re : -1 » Problème Nagios et Postfix » Le 23/06/2008, à 11:51
- Thamior
- Réponses : 22
tu n'as pas besion d'un relai smtp comme postfix , nagios le gere automatiquement .
Je ne suis pas d'accord avec cette affirmation.
Nagios ne gère pas le transport des mails, il utilise seulement la commande "mail" du système. Et cette commande "mail" n'existe que s'il y a un MTA d'installé, comme "sendmail" (par defaut).
#6 Re : -1 » Problème Nagios et Postfix » Le 23/06/2008, à 12:32
- Thamior
- Réponses : 22
D'après les docs officiels d'ubuntu.com :
Postfix is a Mail Transfer Agent (MTA) which is the default MTA for Ubuntu.
#7 Re : -1 » Problème Nagios et Postfix » Le 23/06/2008, à 14:02
- Thamior
- Réponses : 22
Peux tu poster ici le code de ces deux commandes (par défaut dans /etc/nagios/misccommands.cfg) :
host-notify-by-email-ng1
et
notify-by-email-ng1
#8 Re : -1 » Bug, processus sans nom qui s'execute à l'infini ! » Le 01/03/2009, à 14:08
- Thamior
- Réponses : 6
Bug identique sur une installation par défaut (sur une machine virtuelle).
#9 Re : -1 » rsync et cron » Le 23/06/2008, à 14:05
- Thamior
- Réponses : 9
Tu lances ce script sous quel utilisateur ?
Ces dossiers appartiennent-ils tous à cet utilisateur ?
#10 -1 » Interprétation logs Postfix » Le 20/06/2008, à 20:12
- Thamior
- Réponses : 19
Bonjour,
c'est en parcourant mon fichier mail.log que je me suis rendu compte que j'avais besoin de vos lumières.
Je me permet de déposer ici quelques extraits du fichier, dans le but d'avoir une explication détaillée
Pour plus de clarté, j'ai supprimé les éléments de date, heure, hostname. J'ai aussi remplacé mon IP par des "x" et volontairement changé mes adresses mails s'il y a lieu.
En dessous, j'y apporte ce que je pense avoir compris, quand je comprends quelquechose ^^
1 :
postfix/smtpd[12549]: connect from 122-116-17-119.HINET-IP.hinet.net[122.116.17.119]
postfix/smtpd[12549]: warning: non-SMTP command from 122-116-17-119.HINET-IP.hinet.net[122.116.17.119]: CONNECT mx2.mail2000.com.tw:25 HTTP/1.0
postfix/smtpd[12549]: disconnect from 122-116-17-119.HINET-IP.hinet.net[122.116.17.119]
Alors çà, ben, on dira qu'il y a eu connexion SMTP sur le serveur, et qu'il a ensuite essayé d'utiliser une commande CONNECT dans la session SMTP...
2 :
postfix/smtpd[12549]: connect from 122-116-17-119.HINET-IP.hinet.net[122.116.17.119]
postfix/smtpd[12549]: NOQUEUE: reject: RCPT from 122-116-17-119.HINET-IP.hinet.net[122.116.17.119]: 504 5.5.2 <xxx.xxx.xxx.xxx>: Helo command rejected: need fully-qualified hostname; from=<8000_808@hotmail.com> to=<poi@mail2000.com.tw> proto=SMTP helo=<88.191.60.118>
postfix/smtpd[12549]: lost connection after RCPT from 122-116-17-119.HINET-IP.hinet.net[122.116.17.119]
postfix/smtpd[12549]: disconnect from 122-116-17-119.HINET-IP.hinet.net[122.116.17.119]
Le serveur qui s'est connecté au mien n'a pas un nom FQDN ?
3 :
postfix/smtpd[12669]: connect from localhost.localdomain[127.0.0.1]
postfix/smtpd[12669]: 2DD787C093: client=localhost.localdomain[127.0.0.1]
postfix/smtpd[12669]: 2DD787C093: reject: DATA from localhost.localdomain[127.0.0.1]: 503 5.5.0 <DATA>: Data command rejected: Improper use of SMTP command pipelining; from=<admin@domainevirtuel1> to=<christian@domainevirtuel2> proto=ESMTP helo=<localhost>
postfix/smtpd[12669]: warning: non-SMTP command from localhost.localdomain[127.0.0.1]: To: christian@domainevirtuel2
postfix/smtpd[12669]: disconnect from localhost.localdomain[127.0.0.1]
Ici, aucune idée... et ce n'est pourtant que de l'interne. Echange de mail entre des comptes virtuels de mon propre serveur
4 :
postfix/smtpd[12750]: connect from outmail006.ash1.tfbnw.net[69.63.184.106]
postfix/policy-spf[12755]: handler sender_policy_framework: is decisive.
postfix/policy-spf[12755]: : Policy action=PREPEND Received-SPF: pass (facebookmail.com: 69.63.184.106 is authorized to use 'notification+og6fhpdf@facebookmail.com' in 'mfrom' identity (mechanism 'ip4:69.63.184.0/24' matched)) receiver=titan.domainevirtuel1; identity=mfrom; envelope-from="notification+og6fhpdf@facebookmail.com"; helo=mx-out.facebook.com; client-ip=69.63.184.106
postfix/smtpd[12750]: 7C2F17C203: client=outmail006.ash1.tfbnw.net[69.63.184.106]
postfix/cleanup[12757]: 7C2F17C203: message-id=<d442e574c351bb1739d5bbf088cfce88@www.facebook.com>
postfix/qmgr[10588]: 7C2F17C203: from=<notification+og6fhpdf@facebookmail.com>, size=2534, nrcpt=1 (queue active)
postfix/pipe[12758]: 7C2F17C203: to=<marie-aude@domainevirtuel2>, relay=dovecot, delay=2.1, delays=2/0.01/0/0.02, dsn=2.0.0, status=sent (delivered via dovecot service)
Ce log me semble nickel, avec un traitement SPF ok.
5 :
postfix/smtpd[9183]: connect from unknown[222.116.188.73]
postfix/smtpd[9183]: NOQUEUE: reject: RCPT from unknown[222.116.188.73]: 550 5.1.0 <admin@domainevirtuel3>: Sender address rejected: User unknown in virtual mailbox table; from=<admin@domainevirtuel3> to=<wertss33@hanmail.net> proto=SMTP helo=<bmdjhnqo.com>
postfix/smtpd[9183]: lost connection after DATA from unknown[222.116.188.73]
postfix/smtpd[9183]: disconnect from unknown[222.116.188.73]
Celui là ne me plait pas...le gars a du se connecter directement en telnet sur le serveur non ?
Il a d'ailleurs essayé plusieurs fois.
Je comprendrai que personne ne soir intéressé pour répondre à çà, mais qui ne tente rien n'a rien
#11 Re : -1 » Interprétation logs Postfix » Le 21/06/2008, à 17:49
- Thamior
- Réponses : 19
oui, probablement, mais normalement, c'est là que le paramétrage SASL rentre en jeu, s'il trouve un utilisateur existant, il devra s'authentifier pour émettre un message.
#12 Re : -1 » Interprétation logs Postfix » Le 24/06/2008, à 12:44
- Thamior
- Réponses : 19
un tout petit up
#13 Re : -1 » Interprétation logs Postfix » Le 24/06/2008, à 14:19
- Thamior
- Réponses : 19
En fait, c'est pour me rassurer. La manip qui est tenté dans le log n°5 ne peut normalement pas aboutir avec une config SASL, c'est bien çà ? Dans le cas ou il tombe sur une mailbox existante, il devra s'authentifier pour émettre ?
Sinon, j'ai un log que je poste ici un peu plus inquiétant, j'ai l'impression que c'est une belle erreur de conf...
Jun 24 13:55:31 titan postfix/qmgr[10588]: 556CB7C1E0: from=<mail@mafamille.fr>, size=27305, nrcpt=1 (queue active)
Jun 24 13:55:31 titan postfix/qmgr[10588]: 30B9F7C353: from=<do-1099-5045242-350871-9--christian.domainevirtuel3@return.do05.net>, size=29362, nrcpt=1 (queue active)
Jun 24 13:55:31 titan postfix/sendmail[22847]: fatal: no debugger_command variable set up
Jun 24 13:55:31 titan postfix/sendmail[22849]: fatal: no debugger_command variable set up
Jun 24 13:55:31 titan postfix/pipe[22843]: 556CB7C1E0: to=<christian@domainevirtuel3>, relay=dovecot, delay=11847, delays=11847/0.05/0/0.06, dsn=4.3.0, status=deferred (temporary failure. Command output: sendmail: fatal: no debugger_command variable set up )
Jun 24 13:55:41 titan postfix/pipe[22845]: 30B9F7C353: to=<christian@domainevirtuel3>, relay=dovecot, delay=3526, delays=3517/0.02/0/9.1, dsn=4.3.0, status=deferred (temporary failure. Command output: sendmail: fatal: no debugger_command variable set up )
Je ne saisi pas ce qu'il se passe...:/
ps : comme dans les logs cités plus haut, j'ai remplacé mes domaines par des fictifs.
Le postconf -n :
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
inet_interfaces = all
mailbox_size_limit = 0
mydestination = titan.domainevirtuel1, localhost.domainevirtuel1, localhost
myhostname = titan.domainevirtuel1
mynetworks = 127.0.0.0/8
myorigin = domainevirtuel1
recipient_delimiter = +
relayhost =
smtpd_banner = $myhostname ESMTP
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_non_fqdn_sender, reject_unknown_recipient_domain, reject_invalid_helo_hostname, reject_unlisted_recipient, reject_unlisted_sender, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_helo_hostname, reject_unauth_destination, check_policy_service unix:private/policy, reject_rbl_client bl.spamcop.net, reject_rbl_client sbl.spamhaus.org, reject_rbl_client xbl.spamhaus.org, reject_rbl_client cbl.abuseat.org, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/ssl/certs/titan-cert.pem
smtpd_tls_key_file = /etc/ssl/private/titan-key.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_tls_session_cache
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 450
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql/mysql_virtual_alias_maps.cf
virtual_gid_maps = static:8
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql/mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 5000
virtual_transport = dovecot
virtual_uid_maps = static:5000
Il est d'ailleurs très probable, vu mon manque certain de connaissance en la matière, que certaines directives ne soit pas configurées correctement, voir qu'elles ne soit d'aucune utilité.
Je suis vraiment preneur de toutes remarques.
#14 Re : -1 » Interprétation logs Postfix » Le 24/06/2008, à 14:54
- Thamior
- Réponses : 19
le SASL n'intervient pas ici, le message est bloqué avant la verification de l'auth SASL.
Ok, j'ai compris , mais s'il avait forgé le mailfrom avec un user existant, je suppose que c'était ensuite SASL qui intervenait, non ?
Mon master.cf
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
pickup fifo n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgr unix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verify unix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - - - - smtp
relay unix - - - - - smtp
-o fallback_relay=
showq unix n - - - - showq
error unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - - - - lmtp
anvil unix - - - - 1 anvil
scache unix - - - - 1 scache
#
# ====================================================================
#
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
# Dovecot LDA
dovecot unix - n n - - pipe
flags=DRhu user=vmail:mail argv=/usr/lib/dovecot/deliver -d ${recipient}
# SPF
policy unix - n n - - spawn
user=nobody argv=/usr/bin/perl /usr/lib/postfix/policyd-spf-perl
Merci Toniotonio
Ne pas hésiter à me dire si la conf est perfectible (et elle l'est surement), c'est bien quand çà fonctionne mais c'est encore mieux quand c'est configuré aux petits oignons ^^
#15 Re : -1 » Interprétation logs Postfix » Le 24/06/2008, à 16:03
- Thamior
- Réponses : 19
Non plus précisément par "reject_unauth_destination" puisque "hanmail.net" (log 5) n'est pas un de tes domaines
Oui mais si c'est moi qui envoie un mail à hanmail.net (par exemple), çà fonctionne. Est-ce çà veut dire que lorsque Postfix parcourt sa directive "smtpd_recipient_restrictions", dès qu'une condition est rempli (le fait par exemple que j'envoie directement depuis le serveur (permit_mynetworks) ou que je sois authentifié (permit_sasl_authenticated)); il sort de la liste des conditions ?
Autre question, quelle est la directive qui empêche l'open-relay, est ce que le fait de déclaré mynetwork=127.0.0.1 suffit à se protéger de çà ?
Enfin dernière question (pour l'instant ^^), je ne mets à disposition pour ce serveur que du webmail. On est bien d'accord que l'envoi de courrier via le webmail fonctionne parce que mynetwork=127.0.0.1 et permit_mynetwork. Mais si j'utilise un client lourd type "thunderbird", çà ne devrait pas fonctionner, si ? Même si je suis authentifié (SASL), il ne connait tout de même pas l'IP de la machine cliente et devrait refusé.
Merci encore pour vos lumières.
J'espère que je suis explicite...
#16 Re : -1 » Interprétation logs Postfix » Le 24/06/2008, à 16:06
- Thamior
- Réponses : 19
Thamior a écrit :Jun 24 13:55:31 titan postfix/sendmail[22847]: fatal: no debugger_command variable set up
Tu as dovecot < 1.0.1 ?
Tu as mail_debug dans dovecot.conf
oui, j'utilise Dovecot 1.0.rc15.
Quand mail_debug, je ne connaissais pas, c'est simple à mettre en oeuvre ?
Edit : je viens de reagerder le fichier de conf, il semble qu'un simple
mail_debug = yes
suffisent. Cette méthode peut supprimer les
fatal: no debugger_command variable set up
? et afficher le problème de manière plus compréhensible ?
#17 Re : -1 » Interprétation logs Postfix » Le 24/06/2008, à 16:27
- Thamior
- Réponses : 19
Merci pour tes articles que je vais éplucher. Le bouquin que j'ai acheté sur Postfix est démoralisant ^^
Pour revenir à mes logs d'erreur, la modification dans le dovecot.conf n'a rien changé mais un mail_debug=yes n'est peut être pas suffisant.
Autre remarque, dès que je relance le service postfix, j'ai le droit à une ligne supplémentaire dans le mail.err :
Jun 24 17:04:55 titan postfix/sendmail[23629]: fatal: no debugger_command variable set up
Jun 24 17:18:35 titan postfix/sendmail[23696]: fatal: no debugger_command variable set up
Jun 24 17:19:01 titan postfix/sendmail[23787]: fatal: no debugger_command variable set up
Edit :
Je reviens à la charge avec des éléments de réponse. Le problème se situe sur la boite d'un seul utilisateur (christian@domainevirtuel3) et mon mailq se remplie petit à petit :
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
556CB7C1E0 27305 Tue Jun 24 10:38:04 mail@mafamille.fr
(temporary failure. Command output: sendmail: fatal: no debugger_command variable set up)
christian@domainevirtuel3
30B9F7C353 29362 Tue Jun 24 12:56:54 do-1099-5045242-350871-9--christian.domainevirtuel3@return.do05.net
(temporary failure. Command output: sendmail: fatal: no debugger_command variable set up)
christian@domainevirtuel3
2C0147C1E1 12424 Tue Jun 24 17:04:52 stellaprivilege@cab01.net
(temporary failure. Command output: sendmail: fatal: no debugger_command variable set up)
christian@domainevirtuel3
-- 69 Kbytes in 3 Requests.
En regardant la taille de son Maildir, je soupçonne qu'il ai dépassé son quota d'espace disque....
Mais pourquoi les logs sont si peu parlant
#18 Re : -1 » Interprétation logs Postfix » Le 24/06/2008, à 17:25
- Thamior
- Réponses : 19
Ce que tu dois faire suffisament, c'est relire attentivement mon post de 17h20...
Ne le prends pas mal Uggy, mais tu as posté 2 fois de suite, et je n'ai malheureusement vu que le dernier message...
Mea Culpa
Donc au bilan, j'ai supprimé le mail_debug=no de la conf de dovecot.
J'ai augmenté le quota de la boite fautive.
J'ai redémarré postfix et dovecot et aucune ligne no debugger_command variable set up n'est apparu dans mon mail.err
Enfin, j'ai vidé mon mailq avec un postqueue -f.
Ca semble pas mal. Maintenant, il faudra que je sature volontairement une boite "test" pour voir ce que les logs me raconte.
Un grand merci à tout les 2. Vous partagez vos connaissances et c'est appréciable
#19 Re : -1 » server DNS dynamic » Le 10/05/2008, à 13:32
- Thamior
- Réponses : 2
Si çà peut aider, voici ma doc sur la modif du service DHCP pour faire du DNS dynamique :
et si besoin, un petit rappel sur le DNS via Bind9
@+
#20 Re : -1 » Bloqué installation vmware server » Le 08/05/2008, à 22:31
- Thamior
- Réponses : 7
Pour ce problème :
# apt-get install ia32-libs
#21 Re : -1 » Serveur media pour fédérer tous mes fichiers » Le 08/05/2008, à 22:40
- Thamior
- Réponses : 4
Question aux experts, le débit d'une connection wifi permet il d'accéder à des vidéos stockées sur un serveur sans avoir à rapatrier ladite vidéo en local?
Salut,
Tout d'abord pour répondre à cette question, oui (et heureusement, sinon il n'y a pas vraiment d'intéret). Le wifi a ses limites mais VLC n'a jamais bronché pour lire mes vidéos ou de la musique via Samba.
Quand à mon architecture, un PC 24/24 en Debian, plusieurs disques durs, et des services dont samba qui partage l'ensemble de mes données sur toutes mes stations (Portables ou fixes).
#22 Re : -1 » Installation de vmware server 1.05 sur Ubuntu Server Hardy » Le 02/05/2008, à 09:53
- Thamior
- Réponses : 7
Voici les paquets que l'installe sous Debian pour la 1.05.
A vérifier avec une Ubuntu
# apt-get install autoconf automake1.9 libtool flex bison gdb psmisc libc6-dev-amd64 lib64gcc1
++
edit : j'ai oublié les principaux :
# apt-get install ssh openssh-server libx11-6 libx11-dev libxtst6 xinetd linux-headers-`uname -r` build-essential
#23 Re : -1 » [résolu]droits pour dokuwiki » Le 29/04/2008, à 06:31
- Thamior
- Réponses : 5
Au contraire, je pense tout simplement qu'Apache tourne avec l'id par defaut (www-data).
Il faut donc appliquer des droits adequats à ton dossier Wiki
# chmod -R 750 /var/www/Wiki
puis donner ces accès au bon utilisateur, celui d'Apache :
# chown -R www-data:www-data /var/www/Wiki
Voilà pour le début
#24 Re : -1 » Peur avec les IPtables » Le 25/04/2008, à 06:38
- Thamior
- Réponses : 10
Est-ce pour pouvoir lancer ton script à n'importe quel moment ?
Tout à fait
Mes serveurs ne redémarrent jamais, ou alors indépendamment de ma volonté ^^.
Le vidage des règles iptables et fail2ban peut mettre utile lorsque je modifie mes règles et que je relance mon script (suite à nouvelle application ou nouveau service).