Bonsoir
Le 25/03/2013 17:19, admini a écrit :
y a-t-il des gens bien qui s'amusent à faire de la gpo sous samba4 avec
un parc $M$ hétérogène(NT4 worstation, 2k, xp, 7, 8 )?
j'aimerais avoir des feedbacks concernant la gpo, ldap, et tralala .
d'avance merci.
J'ai juste testé Samba4
Le 26/03/2013 09:47, admini a écrit :
ok, et qu''est que la gpo de samba4 est capable de géner? autant de
chose qu'un vrai pdc $M$? c'est à dire, pratiquement tout sur les postes
$M$: tous les aspects passwd, fond de bureau, l'heure
Tout pareil qu'avec Windows. Comme je disais dans mon
Bonsoir,
Désolé je n'avais pas vu la question.
Le 26/03/2013 10:30, agent.sy104 a écrit :
$M$: tous les aspects passwd, fond de bureau, l'heure
Tout pareil qu'avec Windows. Comme je disais dans mon message précédent,
pour paramétrer les GPO on passe par un client Windows et on utilise
Bonjour à tous,
En général, pour rebuilder un paquet Debian, je fais ça :
apt-get update
apt-get devscripts dpkg-dev
apt-get source toto
apt-get build-dep toto
cd le-rep-source-de-toto
# Là, je modifie éventuellement le paquet.
# Ensuite, j'édite le
Re, ;-)
Comme indiqué dans le titre, j'essaye de mettre en
place un boot PXE avec un fichier preseed afin d'avoir
une installation 100% automatique d'une Debian Wheezy
amd64. Il s'avère que je bloque sur 2 trucs.
Je mets toute ma conf en fin de message.
1) Impossible d'avoir le clavier en
Bonjour,
J'ai rencontré des comportements d'Apache2 par rapport aux choix
du vhost desservi que je ne comprenais pas. Après pas mal de
tâtonnements, voici la manipulation minimale qui aboutit à quelque
chose que je n'arrive pas à m'expliquer et qui est, je pense,
le cœur de mon problème.
Soit
Le 07/12/2013 17:05, Philippe Gras a écrit :
dans /etc/apache2/sites-*
le default n'est-il pas toujours présent ?
Comme d'habitude après un a2dissite :
* le fichier default est bien présent dans /etc/apache2/sites-available/
* mais plus rien dans /etc/apache2/sites-enabled/ (et donc plus de
Le 07/12/2013 18:12, Bzzz a écrit :
On Sat, 7 Dec 2013 18:08:11 +0100
Philippe Gras ph.g...@worldonline.fr wrote:
Si ça se trouve, c'est la conf qui doit renvoyer vers /var/www
par défaut, au cas où on oublierait d'activer le module…
Il y a pômal de chances, vu que c'est là que
Le 07/12/2013 18:39, Philippe Gras a écrit :
« au cas où on oublierait d'activer le module », de quel « module »
parlez-vous ?
a2ensite mon_site
Normalement, je crois qu'on n'utilise pas le site par défaut.
A priori non (enfin si on peut utiliser le site par défaut).
Dans la page man de
Bonsoir,
Je tente un petit UP du post ci-dessous. Je pourrais le résumer
en disant tout simplement que je n'arrive pas à désactiver le
site default sur Debian Wheezy.
Le 07/12/2013 16:12, Francois Lafont a écrit :
Bonjour,
J'ai rencontré des comportements d'Apache2 par rapport aux choix
du
Bonjour,
Le 11/12/2013 03:09, Diogene Laerce a écrit :
Tu as verifie le contenu de ports.conf ?
Ma conf est vraiment celle qu'on a avec une Wheezy out of the box après
un simple :
apt-get update apt-get install -y apache2
a2dissite default
service apache2 reload # où même un restart si on
Bonsoir,
Je tente une dernière relance car je n'ai toujours pas
trouvé comment définitivement fermer le clapet du site
default sous Apache2 dans Debian Wheezy.
Merci.
--
François Lafont
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous
Le 14/12/2013 09:26, Sylvain L. Sauvage a écrit :
Le samedi 14 décembre 2013 04:00:21 Bzzz a écrit :
[…]
Tu as du merdouiller qq part; sous sid, la suppression de
/var/www/index.html me renvoie le listing de tous les fichiers
et directories de /var/www/ quand je recharge.
C’est pas le
Le 14/12/2013 12:21, Gaël a écrit :
Salut François,
Salut.
Je tente une dernière relance car je n'ai toujours pas
trouvé comment définitivement fermer le clapet du site
default sous Apache2 dans Debian Wheezy.
Peut-tu nous mettre quelque part tout le contenu de ton dossier /etc/apache2 ?
Le 14/12/2013 17:36, Sylvain L. Sauvage a écrit :
less /tmp/TST/apache2/sites-available/default […]
^
Justement ! Il est dans sites-*available* mais pas dans
sites-*enabled*. Donc il ne devrait pas être servi, comme
c’était bien le cas dans
Le 14/12/2013 18:56, Bzzz a écrit :
En revanche, le « nouveau » vhost test est toujours desservi
même si l'on joue avec l'instruction « ServerName www.truc.fr »
par exemple et que l'on fait une requête via l'IP alors
on tombe quand même sur le « nouveau » vhost test.
Mais j'imagine que ça
Le 14/12/2013 19:37, Bzzz a écrit :
si une
requête ne matche avec aucun ServerName d'aucun vhost et bien je
crois bien qu'Apache2 va quand même desservir un vhost (et je me
demande si ce ne sera pas le premier dans son ordre de lecture de
la conf).
[couic]
Hem, qu'un svr http se permette
Le 14/12/2013 20:56, Bzzz a écrit :
C'est quoi le serveur principal ?
J'ai compris la notion de serveur par défaut (celui sur lequel
on tombe quand rien de matche) mais la notion de serveur
principal, je ne vois pas.
D'après
Bonjour,
(ce message doit être lu avec une police à chasse fixe.)
--%%%%%%%%%--
~# apt-get moo
(__)
(oo)
/--\/
/ |||
* /\---/\
~~ ~~
Have you mooed today?...
~# apt-get update apt-get install -y cowsay
~#
Bonjour,
Le 03/01/2014 12:17, Cyrille a écrit :
Sous sid, avec aptitude;
je voudrais simplement confirmation de la méthode à utiliser :
je pense créer un fichier /etc/apt/apt.conf.d/90recommand-suggest
avec le contenu suivant :
APT
{
Install-Recommends true;
Install-Suggests
Bonsoir,
Le 03/01/2014 18:44, Sylvain L. Sauvage a écrit :
on a seulement la liste des Suggested.
… parce que le paquet weechat n’a pas de Recommends. En
revanche, le paquet weechat-curses dont il « Depends »
« Recommends » weechat-plugins…
Ah ok, merci pour l'info. J'aurais dû y
Bonsoir,
Le 03/01/2014 22:43, Charles Plessy a écrit :
depuis apt 0.7.17 (5 novembre 2008), la valeur par défaut pour
Install-Recommends est « true ». Il n'est donc pas nécessaire d'ajouter un
fichier « /etc/apt/apt.conf.d/90recommand-suggest » comme montré plus haut.
De même, la valeur par
Bonjour,
Le 04/01/2014 23:53, François Patte a écrit :
A chaque upgrade l'état des services est modifié; par exemple:
J'ai éteint rpcbind (chkconfig -level 2345 rpcbind off); aujourd'hui,
j'ai fait une mise à jour et rpcbind est en route... en faisant
chkconfig --list, je peux voir qu'il
Le 05/01/2014 16:10, Erwan David a écrit :
Sinon le moyen debian de désactiver le lancement d'un démon c'est
update-rc.d service disable
Ce ne sera pas « upgrade résistant » à tous les coups.
Si jamais le script postinst du paquet concerné re-configure les
liens symboliques du script init, la
Le 05/01/2014 16:46, Vincent Lefevre a écrit :
On 2014-01-05 15:56:23 +0100, Francois Lafont wrote:
L'idéal pour avoir ce que tu veux, ce sont les services qui ont
le bon goût d'avoir un fichier de conf /etc/default/le-service
avec une instruction du genre :
START=yes
ou encore
DAEMON
Le 05/01/2014 16:58, Erwan David a écrit :
Sinon le moyen debian de désactiver le lancement d'un démon c'est
update-rc.d service disable
Ce ne sera pas « upgrade résistant » à tous les coups.
Si jamais le script postinst du paquet concerné re-configure les
liens symboliques du script init,
Le 05/01/2014 17:35, Erwan David a écrit :
C'est appelé, mais si on a fait un update-rc.d disable, ça ne fait rien :
If any files named /etc/rcrunlevel.d/[SK]??name already exist then
update-rc.d does nothing. The program was written this way so that it
will never change an existing
Bonjour à tous,
Sur une Debian Wheezy à jour, avec une conf APT par défaut,
j'ai ajouté un petit dépôt « maison » via :
echo 'deb http://repository.crdp.ac-versailles.fr/debian wheezy main'
/etc/apt/sources.list.d/perso.list
wget -O - http://repository.crdp.ac-versailles.fr/crdp.gpg | apt-key
Bonsoir,
Le 09/01/2014 19:11, Sylvain L. Sauvage a écrit :
[Tu aurais pu faire un sujet plus court. P.ex. « dépôt maison
pas automatiquement prioritaire ».
Oui, tu as raison. En plus il y a une erreur de syntaxe
dans le titre. Bref... J'aime bien mettre des sujets les plus
explicites et les
Le 09/01/2014 21:59, Jean-Marc a écrit :
Ce que tu as fait est un bon début.
apt-cache te permet de voir quelle est la politique d'install' de tes
paquets. Sans nom de paquet à la fin, cela montre la politique générale de
ton système.
Ok. Merci pour l'info.
Devant les dépôts,
Bonsoir,
Le 11/01/2014 14:45, Jean-Marc a écrit :
1. Ok, et avec ce réglable tu vas pouvoir installer un paquet
de sid *uniquement* via :
apt-get install le-package/unstable
ou bien
apt-get install -t unstable le-package
J'ai bon ?
C'est correct.
2. Au passage, quelle est la
Bonjour,
Le 12/01/2014 12:35, Sylvain L. Sauvage a écrit :
En CLI, toutes les raisons et alternatives ne sont pas
affichées. Il faut les demander ou les rechercher soi-même (à
coups d’apt-cache ou d’apt-rdepends).
Je vais peut-être dire une bêtise mais il me semble qu'on peut
éviter des
Bonjour,
Le 12/01/2014 19:15, François Patte a écrit :
Tu dois avoir un paquet installé qui dépend de « mlterm |
mlterm-tiny » (peut-être un mlterm-im-* ?). apt-get ne veut
évidemment pas laisser ce paquet cassé en supprimant mlterm*, et
il essaie donc de trouver une alternative (soit
Le 13/01/2014 11:45, François Patte a écrit :
Je t’aurais bien comparé au Schtroumpf grognon mais, lui, il
est sympathique.
A tout prendre vaut mieux Schtroumpf grognon que Schtroumpf à lunettes!
Bon et à part ça, le problème est-il résolu ?
--
François Lafont
--
Lisez la FAQ de la
Le 13/01/2014 17:00, François Patte a écrit :
tu as sûrement eu aussi les paquets recommandés qui se sont
installés sur ton système automatiquement (c'est le cas par défaut
depuis Wheezy).
Je constate qu'avec un :
apt-get install --no-install-recommends -y mlterm
apt-get remove -y mlterm
Bonjour à tous,
Je me suis fait un paqckage perso qui consistait simplement
à déposer des fichiers dans /opt/mon-paquet. Je ne suis pas
un expert en packaging mais je pense que le paquet était fait
à peu près correctement (j'ai mis un fichier mon-paquet.install
dans le répertoire de build debian/
Bonjour,
Le 23/01/2014 14:07, Charles Plessy a écrit :
le comportement de dpkg est normal.
Ah, ça me rassure. ;-)
Dans un système standard Debian, c'est le paquet base-files qui contient les
répertoires vides les plus fréquents, pour qu'ils ne soient pas effacés quand
plus aucun autre
Bonjour à tous,
Étant donné un fichier debian/control d'un paquet (pas encore
buildé), y a-t-il une commande ad-hoc pour obtenir la liste des
build-dépendances et leur installation, le tout de manière 100%
*automatique* ?
Attention, le debian/control est issu d'un dépôt, le paquet
n'a pas encore
Bonsoir,
Le 24/01/2014 19:43, Sébastien NOBILI a écrit :
apt-get build-dep le_paquet ?
Ça le fait pas malheureusement.
Ça nécessite qu'une version binaire du paquet soit disponible dans les dépôts
je
crois…
C'est tout le problème et c'est pour ça que j'ai posé la question
sur cette
Bonjour,
Le 24/01/2014 23:50, Charles Plessy a écrit :
pour l'installation automatique, la commande mk-build-deps du paquet
devscripts
devrait faire l'affaire.
Paf, en plein dans le mille ! C'est exactement ce que je cherchais.
J'ajoute juste des précisions des fois que ça serve à d'autres.
Bonjour,
Merci Stéphane pour cette réponse détaillée.
Je me permets de réagir sur un point.
Le 23/01/2014 22:13, Stéphane GARGOLY a écrit :
On aurait pu mettre ton paquet dans le répertoire /usr/local.
Là, je dis non. ;-)
D'après ce que j'ai compris de quelques lectures ici ou là,
aucun
Bonjour,
Le 25/01/2014 01:00, Charles Plessy a écrit :
Donc finalement la règle serait donc : au moment d'un remove les fichiers du
paquet sont supprimés et si un répertoire qui contenait un de ces fichiers
devient vide suite à ce remove alors le répertoire est supprimé aussi *SSI*
il
ne
Bonsoir,
Le 25/01/2014 21:29, Stéphane GARGOLY a écrit :
D'après ce que j'ai compris de quelques lectures ici ou là,
aucun paquet ne doit installer quoi que ce soit dans /usr/local/,
c'est interdit par la loi. :-) Ce répertoire est la chasse gardée
de l'administrateur du système, il peut y
Bonjour,
Le 26/01/2014 13:24, Bzzz a écrit :
On Sun, 26 Jan 2014 02:33:15 +0100
Francois Lafont mathsatta...@free.fr wrote:
Bon, après, il est indiqué qu'un paquet peut quand même créer
des répertoires vides si j'ai bien tout compris.
Non,
C'est vrai que ma lecture a été vraiment
Le 26/01/2014 15:40, Bzzz a écrit :
« However, the package may create *empty* directories
below /usr/local so that the system administrator knows where to
place site-specific files. These are not directories
in /usr/local, but are children of directories in /usr/local.
These directories
Bzzz vraiment je ne comprends la traduction que tu me donnes
(en revanche ton interprétation je l'ai bien comprise). Voir
ci-dessous :
Le 26/01/2014 16:45, Bzzz a écrit :
Ok, je comprends très bien ce que tu m'expliques. C'est juste
que je ne pige pas le « empty » dans la phrase :
« However,
Le 26/01/2014 18:29, Sylvain L. Sauvage a écrit :
Le dimanche 26 janvier 2014 18:02:48 Francois Lafont a écrit :
[… blabla répertoires vides blabla …]
Oui désolé si ce n'est pas passionnant, je reconnais.
Mais j'espère qu'il n'y a pas de mépris quand même derrière
ce commentaire.
Les
Le 26/01/2014 18:17, Bzzz a écrit :
Toutefois, le package peut créer des répertoires vides
^
ok, ces répertoires sont vides (répertoires pas encore
super bien identifiés à ce stade, on sait juste qu'ils
sont « sous /usr/local » ce que
Bonsoir,
Le 26/01/2014 10:45, maderios a écrit :
On aurait pu mettre ton paquet dans le répertoire /usr/local.
Là, je dis non. ;-)
D'après ce que j'ai compris de quelques lectures ici ou là,
aucun paquet ne doit installer quoi que ce soit dans /usr/local/,
Bonjour
Hum... C'est nouveau ?
Le 26/01/2014 21:06, Sylvain L. Sauvage a écrit :
Le dimanche 26 janvier 2014 19:50:22 Francois Lafont a écrit :
[…]
[… blabla répertoires vides blabla …]
Oui désolé si ce n'est pas passionnant, je reconnais.
Mais j'espère qu'il n'y a pas de mépris quand même derrière
ce commentaire
Le 26/01/2014 21:17, Bzzz a écrit :
On Sun, 26 Jan 2014 20:58:59 +0100
Francois Lafont mathsatta...@free.fr wrote:
Mouais, suis pas convaincu.
Dans ce cas, ne pose pas la question.
Désolé Bzzz, mais malheureusement l'apprentissage n'est
pas quelque chose d'algorithmique et de déterministe
Le 26/01/2014 22:37, Bzzz a écrit :
Ensuite, on peut faire des paquets qui ne respectent pas
toutes la Debian policy, ce n'est pas une obligation absolu
contrairement à ce que je pensais au départ.
Toute règle est destinée, tôt ou tard, à être brisée
(dans les limites du raisonnable).
Bonjour,
Le 01/02/2014 12:04, maderios a écrit :
C'est ici, en bon français:
https://linuxfr.org/users/shuba/journaux/debian-a-l-heure-du-choix
Question de béotien : pourquoi vouloir changer (peut-être) le système
init par défaut actuel, ie le System V ? Ce système pose-t-il des problèmes ?
Merci Frédéric et Sylvain pour vos explications et liens.
Ah... c'est toujours perturbant le changement en informatique. ;-)
On verra bien ce que Debian décide.
À+
--
François Lafont
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous
Bonjour à tous,
J'ai une machine sous Debian Wheezy avec ce contrôleur RAID :
~# lspci | grep RAID
02:00.0 RAID bus controller: Areca Technology Corp. ARC-1880 8/12 port
PCIe/PCI-X to SAS/SATA II RAID Controller (rev 05)
Je voudrais avoir à disposition une commande (en console)
qui me permette
Bonjour,
Le 10/04/2014 02:31, Sylvain L. Sauvage a écrit :
Avec un apt-file à jour :
{ apt-file search -l /usr/share/locale/fr
aptitude search --disable-columns -F %p ~i
} | sort | uniq -d | xargs aptitude reinstall
Oh, c'est joli. :)
--
François Lafont
--
Lisez la FAQ de la liste
Bonjour,
Le 25/04/2014 17:30, Bzzz a écrit :
j'ai une erreur en lançant un script shell avec ps (pièce
jointe)...
Pas étonnant, lance la 1ère ligne de Cde à la main
et tu comprendras pourquoi ça plante.
Perso, j'ai ça :
$ kill -9 $(ps -ef |grep mplayer |awk '{print $2}')
bash:
Bonsoir,
Le 26/04/2014 17:14, François TOURDE a écrit :
Perso, j'ai ça :
$ kill -9 $(ps -ef |grep mplayer |awk '{print $2}')
bash: kill: (7159) - No such process
En l'occurrence, je comprends effectivement le message d'erreur
que j'ai ci-dessus.
Par contre, je veux bien qu'on m'explique
Le 28/04/2014 12:17, Jean-Jacques Doti a écrit :
Je soupçonne Bernard de nous cacher certaines informations capitales ;-).
Est-ce que par hasard le shell utilisé serait zsh ? Dans ce cas, il faut
regarder par là :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732410
Merci Jean-Jacques
Bonjour,
Tant mieux si tu as pu résoudre ton problème.
Du coup, je me permets de réagir et de digresser
quelque peu sur ce point là :
Le 09/05/2014 14:38, Gaël a écrit :
Bah, sur ma config d'origine, fournie par l'hébergeur lors de
l'install de l'OS, c'est bien ça.
#auto eth0
#iface eth0
Le 09/05/2014 20:07, Jean Baptiste FAVRE a écrit :
J'avoue que moi aussi, ça me laisse perplexe. D'autant que je ne
vois pas comment la passerelle A.B.C.D peut être atteinte depuis le
'réseau' A.B.C.D/32 (avec D différent de 1, sinon ce n'est pas du jeu).
C'est juste un lien point à
Le 13/05/2014 16:58, Bernard Isambert a écrit :
Le 13/05/2014 16:46, David Guyot a écrit :
Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit:
Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins
chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on
n'a
Le 13/05/2014 18:34, Bzzz a écrit :
Ça n'a pas lieu d'être, parce que la logique veut que l'on
monte l'étage 1 avant le 2,
Mouarf ! Cet argument, c'est juste n'importe quoi mais venant
de toi Bzzz, ça ne m'étonne pas vraiment.
La « logique » veut aussi que, dans la plupart des langages
de
Le 13/05/2014 19:46, Bzzz a écrit :
On Tue, 13 May 2014 19:25:47 +0200
Francois Lafont mathsatta...@free.fr wrote:
Le 13/05/2014 18:34, Bzzz a écrit :
Ça n'a pas lieu d'être, parce que la logique veut que l'on
monte l'étage 1 avant le 2,
Mouarf ! Cet argument, c'est juste n'importe quoi
Bonjour,
Le 22/05/2014 08:51, Nahliel Steinberg a écrit :
Je suis confronté à un problème, je dois changer plus de 300 ip dans un
fichier de configuration de nagios, le hosts.cfg.
Auriez-vous une petite moulinette (script), qui puisse au moins me détecter
le champ address : ip pour les
Le 22/05/2014 09:56, Nahliel Steinberg a écrit :
Non pas du tout, j'ai un fichier de configurattion cfg, qui contient un champ
address : IP
Ok, ça c'est le fichier hosts.cfg. Mais pour changer les
IP, il te faut bien un « document » qui te dit cette IP là
il faudra la changer en ça, celle-ci
Oups, désolé Nahliel, je t'ai répondu en privé au
lieu de passer par la mailing list. On la refait. :)
Le 22/05/2014 10:07, Nahliel Steinberg a écrit :
Le 22/05/14 at 10:04, Francois Lafont a ecrit:
Le 22/05/2014 09:56, Nahliel Steinberg a écrit :
Non pas du tout, j'ai un fichier de
Le 22/05/2014 11:02, Nahliel Steinberg a écrit :
Pourquoi pas, je gagnerai du temps, envoi là qu'on voit comment tu brilles de
tout ton éclat.
Si tu avais dénié expliquer sous quel format *exactement* tu
disposes des modifications à faire (fichier csv, xml, feuille
de papier, que sais-je
Le 22/05/2014 11:30, Francois Lafont a écrit :
Si tu avais dénié expliquer sous quel format *exactement* tu
Oh, désolé pour cette horreur. Il fallait lire :
« si tu avais *daigné* ... »
--
François Lafont
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr
Bonjour,
Le 24/05/2014 16:23, Benoit B a écrit :
Existe-t-il un moyen de savoir quelle est la commande dans mon autostart.sh
qui prend le plus de temps et ressource ? Du genre encadrer chaque commande
par quelque chose qui log le temps qu'il prend et la charge qu'il cause ?
Tu peux toujours
Le 29/05/2014 16:34, Bzzz a écrit :
Et ne te justifie pas, tu as tords de toute façon.
TorT s'écrit avec un T final (penser: tortueux) et le verbe
justifier s'accorde, dans le cas présent, à la seconde personne
du singulier;
Oui mais le temps utilisé est le présent de l'impératif avec un
Bonjour,
Le 07/06/2014 18:16, Philippe Gras a écrit :
=
# iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP
# iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP
# iptables -A INPUT -m state --state
Bonjour à tous,
Le 07/06/2014 23:05, nb a écrit :
Le 07/06/2014 20:31, Philippe Gras a écrit :
Non, justement pas quel que soit l'état de la connexion, et c'est logique.
On n'aurait pas de règle pour les connexions établies, sinon ;-)
Philippe a raison.
INPUT ne sert pas pour une
Le 08/06/2014 13:58, Philippe Gras a écrit :
OK, ce n'est pas Debian, mais Iptables. Mais on peut l'installer sur une
Debian.
Je n'ai pas vu de forum ou de liste dédiée à Iptables, alors je pose ma
question
ici même.
Personnellement, ça ne me dérange absolument que le sujet
soit abordé
Juste pour conclure, je voulais ajouter ceci. Juste après un :
iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP
iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP
*pendant* l'attaque, il est tout à fait possible que ton serveur
apache soit encore dans les choux. En effet,
Bonjour,
Perso, j'en étais resté à l'idée qu'il ne fallait tout simplement
pas définir plusieurs routes par défaut car comme son nom l'indique
*la* route par défaut est unique (c'est *la* utilisée quand aucune
autre route ne matche). Maintenant peut-être que ça se fait malgré
tout, mais dans ma
Le 14/06/2014 13:46, Francois Lafont a écrit :
*la* route par défaut est unique (c'est *la* utilisée quand aucune
^
Oups, désolé il manque un mot. Il faut lire : « c'est *la* route
utilisée ... »
--
François Lafont
--
Lisez la FAQ de la liste
Bonjour à tous,
Sur toutes mes Wheezy (ordi perso, du bureau et mon portable), je
n'arrive pas à faire fonctionner nautilus-open-terminal. Ce paquet,
lorsque je me balade dans l'arborescence de fichiers avec nautilus,
me permet normalement de lancer un terminal directement dans le
répertoire où
Bonjour,
Désolé pour ma réponse tardive.
Le 21/06/2014 10:21, Guillaume Caron a écrit :
Petite piste : essaie de lancer Nautilus depuis un shell, ça te permettra
d'avoir des traces lorsque tu essaieras d'ouvrir un terminal depuis un
dossier.
Merci, c'est une bonne idée en effet. J'aurais
Bonsoir,
Le 30/06/2014 09:28, Guillaume Caron a écrit :
Oups, désolé j'ai lu trop rapidement ton mail et je n'avais pas pigé la
deuxième
partie et tes investigations /o\.
Du coup j'ai raconté n'importe quoi, c'est bien le shell qui doit prendre
l'option « -c » et pas le terminal.
Bonsoir,
Le 21/06/2014 13:55, Diogene Laerce a écrit :
Si ca peut aider : j'utilise ce script dans ~/gnome2/nautilus-script :
#!/usr/bin/perl -w
#
# Open terminal here
#
# Nautilus script that opens a
Bonsoir,
Le 15/07/2014 22:15, Olivier a écrit :
1. Si j'ai bien compris, il est possible de charger un fichier preseed avec
l'option preseed/url=http://foo/preseed.cfg ajoutée à la commande par
défaut de Debian Installer.
Or à ce stade, le réseau n'est pas configuré, si je ne m'abuse.
Bonjour,
Le 25/07/2014 23:32, moi-meme a écrit :
dans un script je veux tuer vim appelé par
xterm -e vim fichier
Je lui envoie un kill -3 %1
Si « ton vim » est la seule tâche en arrière plan
et si ton shell est le bash, alors ceci devrait
marcher :
kill -- -$(jobs -p)
En tout cas,
Le 26/07/2014 13:30, moi-meme a écrit :
kill -- -$(jobs -p)
connaissait pas -p
Mais ça ne me supprime pas le .swp.
Ah ? Sur ma Debian Wheezy (à jour), avec bash comme shell,
ça marche. Voici un copier-coller de ma console :
-
~$ xterm -e vim test.c
[1] 4146
~$ ls
Le 26/07/2014 14:19, Pierre Malard a écrit :
kill -- -$(jobs -p)
En tout cas, sur ma Debian Wheezy, ça marche (j'ai
testé).
Bravo, c’est beaucoup plus propre.
Par contre, si le vi a apporté une modification, on retrouve le .toto.swp...
1. Chez moi, si j'effectue des modifications
Le 26/07/2014 16:46, Pierre Malard a écrit :
Encore une fois, il serait intéressant de savoir pourquoi « moi-même »
souhaite piloter vim dans un xterm pour mieux répondre à la question !
Je suis d'accord. Lancer vim en arrière plan pour
ensuite le killer, alors qu'effectivement vim est
une
Le 26/07/2014 21:02, moi-meme a écrit :
Haricophile m'a donné une voie intéressante qui fait disparaître le swap
en même temps.
Envoyer le signal SIGTERM à la tâche.
Envoyer le signal SIGTERM est ni plus ni moins
ce que je t'ai indiqué dans mon premier message
où j'avais donné la commande :
Le 26/07/2014 21:44, Adrien Dewulf a écrit :
Pour le fichier cacher .swp, je suppose qu'on le voit avec ls -l ?
Non, pour lister tous les fichiers d'un
répertoire, y compris les fichiers « cachés »
(ie ceux dont le nom commence par un point),
tu dois utiliser l'option -a de la commande ls.
--
Le 27/07/2014 17:45, moi-meme a écrit :
Je suis d'accord. Lancer vim en arrière plan pour ensuite le killer,
alors qu'effectivement vim est une commande 100% interactive, c'est
assez curieux. Il est possible que le PO prenne son problème par le
mauvais bout. Peut-être nous en dira-t-il un peu
Le 27/07/2014 23:02, moi-meme a écrit :
Entre 1) et 3), le script, lui, il fait quoi ? Y'a forcément une truc
entre les deux parce que sinon aussitôt le vim ouvert, il serait killé
dans la foulée et tu n'aurais pas le temps d'éditer quoi que ce soit.
entre le 1 et le 3 il y a le 2 (!)
le 2
Le 28/07/2014 07:45, moi-meme a écrit :
Heu... c'est dans la boucle bash ça ? Tu as des commandes bash qui
éditent un fichier sous vim et qui font un « :w » ?
non je l'édite à la main et je fais un :w! à la main, et je ne le ferme
pas. Mon fichier sur le disque est à jour de mes modifs et
Le 28/07/2014 13:55, moi-meme a écrit :
j'ai fait un gros snip. Ce que tu me dis est intyéressant : je suis
peut-être parti sur du compliqué.
Je pense oui, ça arrive à tout le monde.
:w | !bash %
Le problème du !bash c'est les variables :
Exemple de script :
#film_4_fin
convert
Le 29/07/2014 22:34, moi-meme a écrit :
Et tu fais de même pour chacune des variables qui se retrouvent dans le
fichier vim à éditer. À partir de là, quand tu lanceras dans vim :
:w | !bash %
les variables seront bien définies avec les valeurs qu'elles avaient
juste avant la ligne «
Le 30/07/2014 15:11, Sébastien NOBILI a écrit :
Le mercredi 30 juillet 2014 à 12:15, Francois Lafont a écrit :
:w | tester_image.sh %
Attention, il manque un « ! » dans la séquence :
:w | !tester_image.sh %
Ah oui, au temps pour moi. Merci d'avoir rectifié.
Note au passage, je ne
Juste une remarque sur un détail :
Le 29/07/2014 22:34, moi-meme a écrit :
to_do=$(cat selection/$film/action)
eval $to_do
En gros, ces deux lignes reviennent à faire un
« include » du fichier action ce qui se fait
naturellement avec la commande « . ». Donc il
vaut mieux écrire plus
Le 01/08/2014 08:34, Sylvain L. Sauvage a écrit :
En même temps, lancer date, concalc, ou Perl (ou autre langage
de script), c’est toujours lancer un processus de plus dans le
(ba)sh. Donc mon avis, c’est d’utiliser :
— le programme que l’on comprend le mieux ;
(ou qui est le plus
Le 01/08/2014 13:29, Sylvain L. Sauvage a écrit :
Par exemple :
a=1396459867
b=1406879835
diff=$(( b - a ))
days=$(( diff / 86400 ))
# etc.
Oui, du peu que l’on en connaisse, la question originale (une
fois correctement lue) pouvait se traiter en (ba)sh seul :
Le 01/08/2014 18:34, moi-meme a écrit :
J'en tire les conclusions suivantes :
Les manières d'y arriver en Perl ou en Bash sont compliquées au possible.
Ah ? 10 lignes de shell, ça ne me semble pas
si « compliqué au possible » que ça.
Je vais me faire un petit script bash externe :
- en
Bonjour,
Sur chacune des 2 machines, après avoir faire un apt-get update,
que donne un :
apt-cache policy bluez
--
François Lafont
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
Le 03/08/2014 15:43, Gaëtan PERRIER a écrit :
En fait après avoir relancer le processus de mise à jour tout est rentré dans
l'ordre pour bluez.
Ah ok.
Par contre Synaptic est toujours différent malgré que ce soit bien la même
version ???
C'est vraiment sûr que les versions sont différentes
1 - 100 sur 278 matches
Mail list logo
