pinning suite, quels outils système avec un noyau récent de jessie-backport

[Daniel Caillibaud]

Bonsoir,

J'ai installé un noyau récent de jessie-backports (4.6.0-0.bpo.1-amd64) parce 
que j'utilise
btrfs (et que les problèmes parfois rencontrés avec btrfs se raréfient avec les 
évolutions du
noyau).

J'ai donc pris aussi dans backports btrfs-progs (pour les mêmes raisons) et les 
paquets qui me
semblait assez liés au noyau (e2fslibs e2fsprogs irqbalance), mais quid de 
systemd
(voire d'autres) ?

J'aurais tendance à en prendre le moins possible dans backports, mais une fois 
que j'ai pris le
noyau est-ce plus prudent de prendre aussi le reste ?

PS1: on est encore vendredi et je sens déjà venir le troll avec backports+btrfs 
& prudent, mais
c'est pas le but du post ;-)
PS2: c'est sur un host en ext4 avec des vm lxc sous btrfs, d'où les e2fs…

-- 
Daniel

Un intellectuel assis va moins loin qu'un con qui marche.
Michel Audiard

Re: pinning et apt-cache policy

[Daniel Caillibaud]

Le 22/07/16 à 20:44, Vincent Bernat  a écrit :

VB>  ❦ 22 juillet 2016 14:18 CEST, Daniel Caillibaud  :
VB> > Ok, donc avec du
VB> >
VB> >  X
VB> >   Y http://origin… 
VB> >
VB> > Y est la priorité du dépôt, et X la priorité épinglée, c'est la plus 
élevée qui compte ou
VB> > seulement X ?
VB> 
VB> Seulement X.

Merci (en fait apparemment X s'il est >0, sinon Y)

VB> > Package: nginx*
VB> > Pin: release o=nginx
VB> > Pin-Priority: 700
VB> >
VB> > ça donne
VB> >
VB> > nginx:
VB> >   Installé : (aucun)
VB> >   Candidat : 1.10.1-1~jessie
VB> >   Épinglage de paquet : 1.10.1-1~jessie
VB> >  Table de version :
VB> >  1.10.1-1~jessie 700
VB> > 200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
VB> >  1.10.0-1~jessie 700
VB> > 200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
VB> >  1.8.1-1~jessie 700
VB> > 200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
VB> >  1.8.0-1~jessie 700
VB> > 200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
VB> >  1.6.2-5+deb8u1 700
VB> > 500 http://http.debian.net/debian/ jessie/main amd64 Packages
VB> >
VB> >
VB> > Donc j'ai l'impression que c'est uniquement le n° de version qui compte 
car tout le monde
VB> > est à 700, et je pige pas trop pourquoi le paquet debian officiel se 
retrouve avec
VB> >  1.6.2-5+deb8u1 700
VB> > car je pensais que le "o=nginx" de l'épingle à 700 le laisserait de coté, 
avec la
VB> > priorité de son dépôt
VB> 
VB> Par le passé, le globbing était un peu bizarre (ou ne marchait pas, il
VB> fallait juste mettre "*" ou le nom exact du paquet). La page de manuel
VB> ne donne pas d'indice. histoire de voir si c'est un problème de
VB> globbing, que se passe-t'il si tu mets "Package: *" à la place de
VB> "Package: nginx*" ?

Pareil !!!

Mais plus surprenant, si je met 

Package: nginx
Pin: release o=nginx
Pin-Priority: 700

ça donne toujours

nginx:
  Installé : (aucun)
  Candidat : 1.10.1-1~jessie
  Épinglage de paquet : 1.10.1-1~jessie
 Table de version :
 1.10.1-1~jessie 700
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.10.0-1~jessie 700
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.8.1-1~jessie 700
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.8.0-1~jessie 700
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.6.2-5+deb8u1 700
500 http://http.debian.net/debian/ jessie/main amd64 Packages

et avec
Package: nginx-dbg

nginx:
  Installé : (aucun)
  Candidat : 1.6.2-5+deb8u1
 Table de version :
 1.10.1-1~jessie 0
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.10.0-1~jessie 0
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.8.1-1~jessie 0
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.8.0-1~jessie 0
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.6.2-5+deb8u1 0
500 http://http.debian.net/debian/ jessie/main amd64 Packages

nginx-dbg:
  Installé : (aucun)
  Candidat : 1.10.1-1~jessie
  Épinglage de paquet : 1.10.1-1~jessie
 Table de version :
 1.10.1-1~jessie 700
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.10.0-1~jessie 700
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.8.1-1~jessie 700
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.8.0-1~jessie 700
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages

Bizarre non ?
Pourtant j'utilisais pas mal ce genre de conf sous squeeze (avec dotdeb) et ça 
marchait bien
(de mémoire, et d'après mes notes de l'époque), je l'avais plus utilisé depuis 
car plus besoin.

Si je vire les prefs par paquets pour ne laisser que celles par dépôt (en 
mettant une priorité
plus faible aux dépôts tiers), et que j'installe les paquets externes à debian 
en précisant
explicitement leur version la première fois, il va suivre les montées de 
version des dépôts
tiers ?

-- 
Daniel

(écrit dans le livre d'or de plusieurs restaurants parisiens)
Je m'ai bien régaler. signe: Marguerite Duras
Pierre Desproges.


pgpfUhqxSWp3S.pgp
Description: OpenPGP digital signature

Re: pinning et apt-cache policy

[Vincent Bernat]

 ❦ 22 juillet 2016 14:18 CEST, Daniel Caillibaud  :

> VB> > [2] - pourquoi ils sont tous en 990 ?
> VB> > - que signifie le 800 de "1.10.1-1~jessie 800"
> VB> 
> VB> C'est la priorité calculée. Les autres priorités sont celles des
> VB> dépôts. Si tu épinges des paquets comme ici, les deux sont différentes.
>
> Ok, donc avec du
>
>  X
>   Y http://origin… 
>
> Y est la priorité du dépôt, et X la priorité épinglée, c'est la plus élevée 
> qui compte ou
> seulement X ?

Seulement X.

> Package: nginx*
> Pin: release o=nginx
> Pin-Priority: 700
>
> ça donne
>
> nginx:
>   Installé : (aucun)
>   Candidat : 1.10.1-1~jessie
>   Épinglage de paquet : 1.10.1-1~jessie
>  Table de version :
>  1.10.1-1~jessie 700
> 200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
>  1.10.0-1~jessie 700
> 200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
>  1.8.1-1~jessie 700
> 200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
>  1.8.0-1~jessie 700
> 200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
>  1.6.2-5+deb8u1 700
> 500 http://http.debian.net/debian/ jessie/main amd64 Packages
>
>
> Donc j'ai l'impression que c'est uniquement le n° de version qui compte car 
> tout le monde est à 700,
> et je pige pas trop pourquoi le paquet debian officiel se retrouve avec
>  1.6.2-5+deb8u1 700
> car je pensais que le "o=nginx" de l'épingle à 700 le laisserait de coté, 
> avec la priorité de son dépôt

Par le passé, le globbing était un peu bizarre (ou ne marchait pas, il
fallait juste mettre "*" ou le nom exact du paquet). La page de manuel
ne donne pas d'indice. histoire de voir si c'est un problème de
globbing, que se passe-t'il si tu mets "Package: *" à la place de
"Package: nginx*" ?
-- 
Don't diddle code to make it faster - find a better algorithm.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: grub-customizer

[andre_debian]

On Friday 22 July 2016 14:50:03 Belaïd wrote:
> Ce lien a fonctionné pour moi pour l'installation et l'utilisation:
> http://www.linuxserve.com/2015/05/how-to-install-grub-customizer-406-in.html
> Sauvegarde la configuration de grub avant (dossier /etc/grub.d/).

Installation sans erreurs, mais échec :

Le résultat ;
# /opt/grub-customizer-4.0.6/./grub-customizer
 AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/opt/grub-customizer-4.0.6/./grub-customizer' 
as the super user
Authenticating as: root
Password:
 AUTHENTICATION COMPLETE ===
Unable to init server: Impossible de se connecter : Connexion refusée
(grub-customizer:10609): Gtk-WARNING **: cannot open display

En mode user, pareil : 
Unable to init server: Impossible de se connecter : Connexion refusée,
cannot open display

André

> Le 22 juillet 2016 à 11:09,  a écrit :
> > Qui a réussi à installer positivement "grub-customizer"
> > sous Debian ?
> > Le paquet existe mais que pour Ubuntu.
> > Apparemment, on peut l'installer pour Debian (Jessie et Wheezy),
> > avec PPA ou sans.
> > Je souhaiterai, avant de me lancer dans l'installation,
> > avoir un petit retour d'expérience.

Re: Certificats SSL

[Daniel Caillibaud]

Le 22/07/16 à 16:22, "Ph. Gras"  a écrit :

PG> > Pas besoin, tu attends d'avoir ton nouveau certificat, tu le met à la 
place de l'ancien
PG> > (que tu as sauvegardé à coté) et reload apache, puis tu vérifie dans ton 
navigateur que
PG> > ça marche (sinon tu remet l'ancien et nouveau reload).  
PG> 
PG> Un truc du style mv example.com.crt old-example.com.crt ?

Oui, 
cd leBonDossier
mv example.com.crt example.com.crt.old
cp /path/to/new.example.com.crt example.com.crt
service apache2 reload

# tester avec un navigateur et en donnant une url https à manger à un 
vérificateur
# parmi https://www.qwant.com/?q=check+ssl+certificate
# et si c'est pas bon, remettre l'ancienne conf
mv example.com.crt.old example.com.crt
service apache2 reload

# et chercher ce qui coince
# ça peut être juste la chaine de certificats à ajouter dans la conf apache
# (cf la doc de gandi qui doit expliquer comment mettre les siens)

Sinon, y'a plein de tutos pour installer letsencrypt, qui se charge tout seul 
de renouveler
le certif ;-)

-- 
Daniel

Les arbres sont responsables de plus de pollution aérienne que les usines.
Ronald Reagan

Re: Certificats SSL

[Ph. Gras]

Merci Daniel :-)

> 
> Heureusement, openssl fonctionne comme toutes les autres commandes, les 
> fichiers donnés en
> arguments sont en absolus s'il commencent par / et en relatif au dossier 
> courant sinon

J'ignorais cela, mais à la réflexion ça paraît très logique. Je vais me coucher 
rasséréné ce soir :-)
> 
> PG> Savez-vous par quelle voie (naturelle ou pas) Gandi fournit le CRT ?
> 
> Pour gandi je sais pas, mais en général tu crée ton csr, le fournit à une 
> autorité de
> certification (ici gandi) et il te renvoient un cert (soit via leur 
> interface, soit avec un
> mail te disant comment le récupérer).

C'est effectivement ce qui s'est produit, Ô magie de l'Internet ! Avec un petit 
wget qui va bien…
> 
> PG> D'un point de vue pratique et durant cette opération, ne vaut-il pas 
> mieux pour
> PG> préserver une continuité du service inverser toutes les redirections du 
> port 443
> PG> vers le port 80 ?
> 
> Pas besoin, tu attends d'avoir ton nouveau certificat, tu le met à la place 
> de l'ancien (que
> tu as sauvegardé à coté) et reload apache, puis tu vérifie dans ton 
> navigateur que ça marche
> (sinon tu remet l'ancien et nouveau reload).

Un truc du style mv example.com.crt old-example.com.crt ?
> 
> Attention, si le nouveau n'a pas été généré avec la même clé privé du 
> serveur, faut aussi la
> changer (soit remplacer le fichier soit changer le chemin dans la conf 
> apache).

Oui, ça va sans dire… La prochaine fois je le ferai avec la même !

Bonne journée,

Ph. Gras

Re: grub-customizer

[Belaïd]

Bonjour,

Ce lien a fonctionné pour moi pour l'installation et l'utilisation:
http://www.linuxserve.com/2015/05/how-to-install-grub-customizer-406-in.html

Sauvegarde la configuration de grub avant (dossier /etc/grub.d/).
Bonne journée


Le 22 juillet 2016 à 11:09,  a écrit :

> Bonjour à tous,
>
> Qui a réussi à installer positivement "grub-customizer"
> sous Debian ?
>
> Le paquet existe mais que pour Ubuntu.
>
> Apparemment, on peut l'installer pour Debian (Jessie et Wheezy),
> avec PPA ou sans.
>
> Je souhaiterai, avant de me lancer dans l'installation,
> avoir un petit retour d'expérience.
>
> Merci.
>
> André
>
>


-- 
< Belaid >

Re: grub-customizer

[Daniel Caillibaud]

Le 22/07/16 à 11:09, andre_deb...@numericable.fr a écrit :

AF> Bonjour à tous,
AF> 
AF> Qui a réussi à installer positivement "grub-customizer"
AF> sous Debian ?
AF> 
AF> Le paquet existe mais que pour Ubuntu.
AF> 
AF> Apparemment, on peut l'installer pour Debian (Jessie et Wheezy),
AF> avec PPA ou sans.
AF> 
AF> Je souhaiterai, avant de me lancer dans l'installation,
AF> avoir un petit retour d'expérience.

C'est plus prudent, je sais pas à quoi il sert mais vu son nom je me méfierait 
(ça me parait
pas prudent de rajouter une surcouche à un truc aussi sensible que grub, 
surtout si ça vient
pas du dépôt debian de ton grub et ton noyau).

-- 
Daniel

"Attention ! J'ai le glaive vengeur et le bras séculier !
L'aigle va fondre sur la vieille buse !...
- Un peu chouette comme métaphore, non?
- C'est pas une métaphore, c'est une périphrase.
- Fais pas chier !...
- Ca, c'est une métaphore."
Michel Audiard

Re: Certificats SSL

[Daniel Caillibaud]

Le 22/07/16 à 10:48, "Ph. Gras"  a écrit :

PG> Merci Vincent :-)
PG> 
PG> >> openssl req -nodes -newkey rsa:2048 -sha256 -keyout monserveur.key -out 
serveur.csr
PG> >> 
PG> >> Ma question est quand j'exécute cette commande, est-ce que le fichier du 
certificat va se
PG> >> placer dans /etc/ssl/certs où que je l'exécute, et la clé dans
PG> >> /etc/ssl/private ?
PG> > 
PG> > Les deux fichiers mentionnés dans la commande se retrouveront dans le
PG> > répertoire en cours. Il n'y a pas encore de certificat à cette étape
PG> > (c'est Gandi qui le fournira après leur avoir donné le CSR).
PG> > -- 
PG> 
PG> c'est parfaitement exact ! Je viens de les créer dans /tmp et j'ai pu les 
comparer
PG> avec ceux qui se trouvent dans /etc/ssl.

Heureusement, openssl fonctionne comme toutes les autres commandes, les 
fichiers donnés en
arguments sont en absolus s'il commencent par / et en relatif au dossier 
courant sinon

PG> Savez-vous par quelle voie (naturelle ou pas) Gandi fournit le CRT ?

Pour gandi je sais pas, mais en général tu crée ton csr, le fournit à une 
autorité de
certification (ici gandi) et il te renvoient un cert (soit via leur interface, 
soit avec un
mail te disant comment le récupérer).

PG> D'un point de vue pratique et durant cette opération, ne vaut-il pas mieux 
pour
PG> préserver une continuité du service inverser toutes les redirections du 
port 443
PG> vers le port 80 ?

Pas besoin, tu attends d'avoir ton nouveau certificat, tu le met à la place de 
l'ancien (que
tu as sauvegardé à coté) et reload apache, puis tu vérifie dans ton navigateur 
que ça marche
(sinon tu remet l'ancien et nouveau reload).

Attention, si le nouveau n'a pas été généré avec la même clé privé du serveur, 
faut aussi la
changer (soit remplacer le fichier soit changer le chemin dans la conf apache).

-- 
Daniel

Reporter : What's your longevity secret ?
Winston Churchill : Whisky, cigars and no sports.
(il aurait en fait répondu "low sport", mais la légende est plus drôle)

Re: pinning et apt-cache policy

[Daniel Caillibaud]

Le 21/07/16 à 22:53, Vincent Bernat  a écrit :
Merci pour toutes ces précisions.

VB> > [2] - pourquoi ils sont tous en 990 ?
VB> > - que signifie le 800 de "1.10.1-1~jessie 800"
VB> 
VB> C'est la priorité calculée. Les autres priorités sont celles des
VB> dépôts. Si tu épinges des paquets comme ici, les deux sont différentes.

Ok, donc avec du

 X
  Y http://origin… 

Y est la priorité du dépôt, et X la priorité épinglée, c'est la plus élevée qui 
compte ou
seulement X ?

Parce qu'en modifiant comme tu l'indiquais, avec en préférences

Package: *
Pin: release n=jessie-backports
Pin-Priority: 300

Package: *
Pin: release o=nginx
Pin-Priority: 200 
  
# On a un noyau 4.6 et btrfs from backport (linux-image-4.6.0-0.bpo.1-amd64)
Package: btrfs-progs dmidecode e2fslibs e2fsprogs irqbalance lxc smartmontools 
unbound unbound-host 
Pin: release n=jessie-backports
Pin-Priority: 600
  
Package: nginx*
Pin: release o=nginx
Pin-Priority: 700

ça donne

nginx:
  Installé : (aucun)
  Candidat : 1.10.1-1~jessie
  Épinglage de paquet : 1.10.1-1~jessie
 Table de version :
 1.10.1-1~jessie 700
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.10.0-1~jessie 700
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.8.1-1~jessie 700
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.8.0-1~jessie 700
200 http://nginx.org/packages/debian/ jessie/nginx amd64 Packages
 1.6.2-5+deb8u1 700
500 http://http.debian.net/debian/ jessie/main amd64 Packages


Donc j'ai l'impression que c'est uniquement le n° de version qui compte car 
tout le monde est à 700,
et je pige pas trop pourquoi le paquet debian officiel se retrouve avec
 1.6.2-5+deb8u1 700
car je pensais que le "o=nginx" de l'épingle à 700 le laisserait de coté, avec 
la priorité de son dépôt

-- 
Daniel

Plus on avance dans la vie, plus on est obligé d'admettre que le sel
de l'existence est essentiellement dans le poivre qu'on y met.
Alphonse Allais


pgpsPskRYRo6w.pgp
Description: OpenPGP digital signature

grub-customizer

[andre_debian]

Bonjour à tous,

Qui a réussi à installer positivement "grub-customizer"
sous Debian ?

Le paquet existe mais que pour Ubuntu.

Apparemment, on peut l'installer pour Debian (Jessie et Wheezy),
avec PPA ou sans.

Je souhaiterai, avant de me lancer dans l'installation,
avoir un petit retour d'expérience.

Merci.

André

Re: Certificats SSL

[Ph. Gras]

Merci Vincent :-)

>> openssl req -nodes -newkey rsa:2048 -sha256 -keyout monserveur.key -out 
>> serveur.csr
>> 
>> Ma question est quand j'exécute cette commande, est-ce que le fichier du 
>> certificat va se
>> placer dans /etc/ssl/certs où que je l'exécute, et la clé dans
>> /etc/ssl/private ?
> 
> Les deux fichiers mentionnés dans la commande se retrouveront dans le
> répertoire en cours. Il n'y a pas encore de certificat à cette étape
> (c'est Gandi qui le fournira après leur avoir donné le CSR).
> -- 

c'est parfaitement exact ! Je viens de les créer dans /tmp et j'ai pu les 
comparer
avec ceux qui se trouvent dans /etc/ssl.

Savez-vous par quelle voie (naturelle ou pas) Gandi fournit le CRT ?

D'un point de vue pratique et durant cette opération, ne vaut-il pas mieux pour
préserver une continuité du service inverser toutes les redirections du port 443
vers le port 80 ?

Je sors un peu du sujet, là… Désolé.

D'avance, je vous remercie.

Ph. Gras