25/08/2014

Another Home Page Blog >> CentOS Dojo Paris

Par : Nils
Tags:

Version en français plus bas.

For once, this blog post is available both in french and in english. Today I attended the first CentOS Dojo in Paris. I also had the chance to be one of the speakers, wich was a very interesting experience : even if I am almost used to talk to a crowd, it was a long time since I used a microphone (more than 10 years if I remember correctly). Moreover, it was my first talk in english, and the demo I planned failed. Since all the talks of the day were recorded, I'm not going to tell you who talked about what. You can go to my Twitter account or search tweets with the hashtag #centosdojo. However I can't help thinking again about my talk and the problem in my demo. My frustration is compensated by the fact that everyone was really nice to me. Like I tweeted earlier, I learned the lesson and won't try another live demo soon. While waiting for the recordings to be online, you can download the slides, in french or in english. Many thanks to Zenika, Normation and InfoQ for sponsoring the event !

Pour une fois, ce billet est en français et en anglais. Aujourd'hui j'ai assisté au premier CentOS Dojo à Paris. J'ai aussi eu la chance d'être l'un des intervenants, ce qui fut une expérience très intéressante : même si j'ai à peu près l'habitude de parler en public, je n'ai pas utilisé de micro depuis très longtemps (plus de 10 ans si je me souviens bien). De plus, cela a été ma première présentation en anglais, et la démo que j'avais prévue n'a pas fonctionné. Puisque toutes les présentations du jour ont été enregistrées, je ne vais pas vous raconter qui a parlé de quoi. Vous pouvez simplement aller voir sur mon compte Twitter ou rechercher les tweets ayant pour hashtag #centosdojo. Cependant, je ne peux m'empêcher de penser à ma présentation et au problème lors de ma démo. Ma frustration est compensée par le fait que tout le monde a été sympa avec moi. Comme je l'ai tweeté plus tôt, j'ai compris la leçon et je ne vais pas tenter des démonstrations en direct. En attendant que les enregistrements soient en ligne, vous pouvez télécharger les slides, en français ou en anglais. Merci beaucoup à Zenika, Normation et InfoQ d'avoir sponsorisé l'évènement !


20/08/2014

Mon chti blog >> Un domU OpenBSD à ma façon

Tags:
openbsd
xen

Pour la recette d'aujourd'hui il nous faudra:

Le matériel

C'est un HP Compaq 6710b:

Le logiciel

L'installation de NetBSD est des plus classique:

  PV Name               /dev/rwd0e
  VG Name               vg0
  PV Size               127.06 GiB / not usable 3.27 MiB
  --- Logical volume ---
  LV Name                /dev/vg0/openbsd-001
  VG Name                vg0
  ...
  LV Size                20.00 GiB
  ...

Les extensions de virtualisation sont bien présentes:

dsx@dom0>sudo xl dmesg
(XEN) Xen version 4.2.4 (pbulk@) (gcc (NetBSD nb2 20110806) 4.5.3) Fri Apr  4 12:02:16 UTC 2014
...
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN) HVM: ASIDs disabled.
(XEN) HVM: VMX enabled
...
dsx@dom0>sudo xl info | grep hvm
virt_caps              : hvm
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 

Le réseau

Le dom0 possède:

Comme j'ai la main sur mon réseau, ma passerelle possède une route vers 10.40.20/24. J'ai aussi les entrées DNS suivantes:

dsx@dom0>dig dom0-gw.bsdsx.fr +short
10.40.20.1
dsx@dom0>dig dom0.openbsd.bsdsx.fr +short
10.40.20.1

La recette du jour

J'aime les installations en mode texte. J'aime les installations au travers du réseau. J'aime les consoles série. Je vais donc installer un domU OpenBSD 5.5 en pxe et console série en étant connecté en ssh au portable.

Préparation

Comme je risque de faire plusieurs essais / tests / installations, je prépare la récupération des sets:

dsx@dom0>ls /xen/http/dom0.openbsd.bsdsx.fr/pub/OpenBSD/5.5/amd64/
INSTALL.amd64 SHA256.sig    bsd           bsd.rd        etc55.tgz     index.txt     pxeboot       xbase55.tgz   xfont55.tgz   xshare55.tgz
SHA256        base55.tgz    bsd.mp        comp55.tgz    game55.tgz    man55.tgz     site55.tgz    xetc55.tgz    xserv55.tgz

Qui dit pxe dit dhcp et tftp. Pour le dhcp, c'est du classique:

dsx@dom0>cat /etc/dhcpd.conf
subnet 10.40.20.0 netmask 255.255.255.0 {
    option routers 10.40.20.1;
    option domain-name-servers 172.16.10.20, 172.16.10.21;
    option domain-name "bsdsx.fr";
    pool {
        max-lease-time 28800;
        range 10.40.20.10 10.40.20.199;
        deny unknown-clients;
        host openbsd-001 {
            hardware ethernet 00:16:3e:00:12:04;
            fixed-address 10.40.20.12;
            filename "pxeboot";
            next-server 10.40.20.1;
        }
    }
}

Pour le tftp et le http, c'est inetd qui vient à la rescousse:

dsx@dom0>grep -v ^# /etc/inetd.conf
dom0-gw:http    stream  tcp   nowait:600  _httpd  /usr/libexec/httpd  httpd -V -v /xen/http /xen/http/_default
dom0-gw:tftp    dgram   udp   wait        root    /usr/libexec/tftpd  tftpd -l -s /xen/tftpboot

Je restreint l'écoute des service à une seule ip et j'utilise la fonctionnalité 'virtualhost' de httpd

Il me reste à peupler le tftp:

dsx@dom0>ls -Rl /xen/tftpboot/
total 17092
-rw-r--r--  1 dsx  wheel  8643177 Aug 23 13:06 bsd.rd
drwxr-xr-x  2 dsx  wheel      512 Aug 24 08:42 etc
-rw-r--r--  1 dsx  wheel    80436 Aug 23 13:06 pxeboot
/xen/tftpboot/etc:
total 4
-rw-r--r--  1 dsx  wheel  48 Aug 24 08:42 boot.conf
dsx@dom0>cat /xen/tftpboot/etc/boot.conf
stty com0 115200
set tty com0
boot tftp:/bsd.rd

Exécution

La configuration du domU est assez simple:

builder = 'hvm'
memory = 256
name = 'openbsd-001.bsdsx.fr'
vif = [ 'mac=00:16:3e:00:12:04, bridge=bridge4, model=e1000' ]
disk = [ 'phy:/dev/mapper/vg0-openbsd--001,ioemu:xvda,rw' ]
boot = 'n'
serial = 'pty'
vnc = 0

Pas la peine de me faire remarquer qu'il eut été judicieux de remplacer e1000 par virtio:

dsx@dom0>ls /usr/pkg/share/xen/qemu/pxe*
/usr/pkg/share/xen/qemu/pxe-e1000.bin              /usr/pkg/share/xen/qemu/pxe-pcnet.bin
/usr/pkg/share/xen/qemu/pxe-ne2k_pci.bin           /usr/pkg/share/xen/qemu/pxe-rtl8139.bin

Il est temps de faire un premier essai:

dsx@dom0>sudo xl create /xen/etc/openbsd-hvm.cfg -c
Parsing config from /xen/etc/openbsd-hvm.cfg
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->0000000000171de4
  TOTAL:         0000000000000000->000000000f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x000000000000007b
  1GB PAGES: 0x0000000000000000
Daemon running with PID 5714
net0: 00:16:3e:00:12:04 on PCI00:03.0 (open)
  [Link:up, TX:0 TXE:0 RX:0 RXE:0]
DHCP (net0 00:16:3e:00:12:04).... ok
net0: 10.40.20.12/255.255.255.0 gw 10.40.20.1
Booting from filename "pxeboot"
tftp://10.40.20.1/pxeboot. ok
>> OpenBSD/amd64 PXEBOOT 3.23
cannot open tftp:/etc/random.seed: No such file or directory
booting tftp:/bsd.rd: 4190944+963509+2917168+0+520928 [100+342504+222489]=0xcbd590
entry point at 0x10001e0 [7205c766, 34000004, 24448b12, 55c8a304]
Copyright (c) 1982, 1986, 1989, 1991, 1993
  The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2014 OpenBSD. All rights reserved.  http://www.OpenBSD.org
OpenBSD 5.5 (RAMDISK_CD) #237: Wed Mar  5 09:43:42 MST 2014
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 242933760 (231MB)
avail mem = 231628800 (220MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb01f (11 entries)
bios0: vendor Xen version "4.2.4" date 07/10/2014
bios0: Xen HVM domU
acpi0 at bios0: rev 2
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 11, 48 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz, 2095.13 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,NXE,LONG,LAHF,PERF
cpu0: 3MB 64b/line 8-way L2 cache
cpu0: apic clock running at 100MHz
acpiprt0 at acpi0: bus 0 (PCI0)
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
"Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <QEMU HARDDISK>
wd0: 16-sector PIO, LBA48, 20480MB, 41943040 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 disabled (no drives)
"Intel 82371AB Power" rev 0x01 at pci0 dev 1 function 3 not configured
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x03: apic 1 int 28, address 00:16:3e:00:12:04
isa0 at mainbus0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
softraid0 at root
scsibus0 at softraid0: 256 targets
PXE boot MAC address 00:16:3e:00:12:04, interface em0
root on rd0a swap on rd0b dump on rd0b
erase ^?, werase ^W, kill ^U, intr ^C, status ^T
Welcome to the OpenBSD/amd64 5.5 installation program.
Starting non-interactive mode in 5 seconds...
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
# halt
syncing disks... done
The operating system has halted.
Please press any key to reboot.

Quelques remarques:

La touche finale

Depuis la version 5.3, OpenBSD est capable d'utiliser les drivers virtio (que je ne peux pas utiliser pour le pxe). La version 5.5 amène une fonctionnalité bien pratique: autoinstall.

Après un peu de lecture, j'établis le plan suivant:

Le répertoire /xen/tftpboot:

dsx@dom0>ls -l /xen/tftpboot/
total 17092
lrwxr-xr-x  1 dsx  wheel        7 Aug 24 11:14 auto_install -> pxeboot
-rw-r--r--  1 dsx  wheel  8643177 Aug 23 13:06 bsd.rd
drwxr-xr-x  2 dsx  wheel      512 Aug 24 10:24 etc
-rw-r--r--  1 dsx  wheel    80436 Aug 23 13:06 pxeboot

Le fichier /xen/http/_default/install.conf:

System hostname = openbsd-001
Network interfaces = em0
IPv4 address for em0 = dhcp
Password for root = monsupermotdepasse
Do you expect to run the X Window System = no
Change the default console to com0 = yes 
Which speed should com0 use = 115200
Setup a user = dsx
Full name for user dsx = Admin user
Password for user = *************
Public ssh key for user = ssh-rsa AAAA...
What timezone are you in = Europe/Paris
Location of sets = http 
Server = dom0.openbsd.bsdsx.fr
Set name(s) = site55.tgz
Checksum test for site55.tgz failed. Continue anyway = yes
Unverified sets: site55.tgz. Continue without verification = yes

Le fichier site55.tgz est composé d'un unique script:

dsx@dom0>cat install.site 
#!/bin/sh
set -x
cp /etc/hostname.em0 /etc/hostname.vio0
export PKG_PATH=ftp://ftp.fr.openbsd.org/pub/OpenBSD/`uname -r`/packages/`uname -m`
pkg_add -r tcsh vim--no_x11 rsync-- fossil--
usermod -s /usr/local/bin/tcsh dsx
echo 'sndiod_flags=NO' >> /etc/rc.conf.local
echo '%wheel        ALL=(ALL) NOPASSWD: SETENV: ALL' >> /etc/sudoers
sed '/^ttyC/ s/on/off/' /etc/ttys > /etc/ttys.serial && mv /etc/ttys.serial /etc/ttys
dsx@dom0>chmod +x install.site 
dsx@dom0>tar czvf /xen/http/dom0.openbsd.bsdsx.fr/pub/OpenBSD/5.5/amd64/site55.tgz install.site

Pour qu'il soit pris en compte il faut mettre à jour le fichier index.tx:

dsx@dom0>cd /xen/http/dom0.openbsd.bsdsx.fr/pub/OpenBSD/5.5/amd64/ && rm index.txt && ls -l > index.txt

J'ai préféré l'utilisation d'une clef pour me connecter en ssh, je n'ai donc pas de mot de passe valide ce qui m'oblige à rajouter une entrée dans /etc/sudoers. Un petit man pkg_add pour réviser les flavors afin d'installer mes paquets indispensables et c'est prêt.fichier autoinstall_55.tx, 177 lignes, 10Ko.

Le fichier de configuration du domU devient:

dsx@dom0>cat /xen/etc/openbsd-hvm.cfg
builder = 'hvm'
memory = 256
name = 'openbsd-001.bsdsx.fr'
vif = [ 'mac=00:16:3e:00:12:04, bridge=bridge4, model=virtio' ]
disk = [ 'phy:/dev/mapper/vg0-openbsd--001,xvda,rw' ]
boot = 'c'
serial = 'pty'
vnc = 0
on_reboot="destroy"

Pour finir

On ne peut pas dire qu'une installation d'OpenBSD prenne du temps ou soit difficile (une touche Entrée en état de marche semble le seul pré-requis). Mais avec l'autoinstall, on atteint un niveau de loutritude olympique. Et encore une fois, tout ça à l'aide de NetBSD et Xen :)


13/08/2014

Emile "iMil" Heitor 's home >> Holidays (IT)checklist

Par : iMil
Tags:
Blogroll
Ibiza

Well, it’s that time of the year again, next week I’ll be flying to my beloved Ibiza.

Being an Internet/IT junkie, I don’t exactly “disconnect”; actually I like to read / dig / test some new topics while on holidays (and while I’m not at the beach / clubbing / sunbathing). So every year I go through a particular “checklist” in order to be sure I can connect to the Internet no matter what, here’s the list as of now:

Any idea that comes to mind? :)

The post Holidays (IT)checklist appeared first on Emile "iMil" Heitor 's home.


11/08/2014

Emile "iMil" Heitor 's home >> virt-manager: “nc: unix connect failed”

Par : iMil
Tags:
Blogroll
FreeBSD
KVM
libvirt

I came across an annoying behaviour while trying to connect to a remote KVM hypervisor from a FreeBSD GUI. virt-manager failed to connect to the server and showed the following error message:

libvirtError: End of file while reading data: nc: unix connect failed: No such file or directory: Input/output error

In short, virt-manager tries to access to /usr/local/var/run/libvirt/libvirt-sock because it is compiled with a /usr/local PREFIX on FreeBSD. Of course they didn’t plan anything on a plain text configuration file. I figured out this has to be configured in GConf, for example using gconf-editor, simply replace:

qemu+ssh://user@host/system

with:

qemu+ssh://user@host/system?socket=/var/run/libvirt/libvirt-sock

Other parameters for remote URIs can be found at this address.

The post virt-manager: “nc: unix connect failed” appeared first on Emile "iMil" Heitor 's home.


08/08/2014

Emile "iMil" Heitor 's home >> FreeBSD 10, KMS and Intel 4500MHD

Par : iMil
Tags:
Blogroll

I recently borrowed a Dell machine at work, model E4300, a nice little laptop whose graphical display is done by a much common Intel 4500MHD. While the card worked out of the box for a classical 2D display with a fresh FreeBSD 10.0 install, I noticed that DRM/DRI (in short, 3D) wasn’t available; I knew it was somewhat related to the new KMS/GEM infrastructure, so I began a few searches and found those useful resources:

Those pages gave bits and pieces of information, but stack a lot of useless complex information for the newcomer. Actually, setting up KMS on FreeBSD 10 is pretty simple. Olivier and farfa gave me the right link: a post on the FreeBSD announce mailing list which explains that there’s an alternative repository for what they call “NEW_XORG”, aka Xorg 1.12.4 with KMS. Simply create a new pkg configuration file in /usr/local/etc/pkg/repos/FreeBSD_new_xorg.conf (create the directory if it does not exist), it must contain the following:

FreeBSD_new_xorg: {
   url: "pkg+http://pkg.FreeBSD.org/${ABI}/new_xorg",
   mirror_type: "srv",
   signature_type: "fingerprints",
   fingerprints: "/usr/share/keys/pkg",
   enabled: yes
}

Then run:

# pkg update -f
# pkg upgrade

You should be asked whether or not you want to upgrade a couple of packages, and among them, some Xorg-related packages.

There was one glitch on this process, xf86-input-keyboard and xf86-input-mouse actually have the same version in the standard pkg repository and the WITH_NEW_XORG repository, so it is mandatory to delete them using:

# pkg delete -f xf86-input-mouse xf86-input-keyboard

Then add:

WITH_NEW_XORG=yes

to /etc/make.conf, ensure your ports tree is up to date by running:

# portsnap fetch update

and rebuild xf86-input-keyboard and xf86-input-mouse with portmaster:

# portmaster x11-drivers/xf86-input-mouse x11-drivers/xf86-input-keyboard

If you don’t do this, Xorg will start but its log will explain the mouse and keyboard driver ABI mistmatches Xorg current version.

Restart Xorg, and enjoy your GLX-enabled environment :)

The post FreeBSD 10, KMS and Intel 4500MHD appeared first on Emile "iMil" Heitor 's home.


07/08/2014

GCU-Squad! >> ifconfig^Warp^Wnetstat^Wroute^Wip

Par : pinpin
Tags:
IP
Irc
Linux
arp
commands
deprecated
ifconfig
netstat

Thx to gradator, une cheatsheet parfaite pour se souvenir ce qu’on est sensé utiliser sous linux en 2014 pour récupérer des infos sur le réseau. En attendant les équivalents systemd pour 2015..

http://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/ proposé par gaston sur #GCU@freenode


04/08/2014

GCU-Squad! >> IT threats Q2 2014

Par : pinpin
Tags:
Irc
infosec

Si ça c’est pas un panorama relativement complet et exhaustif de tout ce qui se fait en termes de fraudes, exploits et autres arnaques. Ça va couper un peu dans votre productivité…

https://securelist.com/analysis/quarterly-malware-reports/65340/it-threat-evolution-q2-2014/ proposé par Seb sur #GCU@freenode


31/07/2014

Weblog de Natacha >> Le transfert de fichiers en 2014

Par : Natacha Kerensikova
Tags:
Geek

Supposons que l'on ait un fichier, ou un ensemble de fichiers (au besoin rassemblés dans une archive), sur un ordinateur que je vais appeler Alpha, parce que ce serait dégradant de lui donner un prénom féminin.

Le problème dont il va être question dans tout cet article va être de faire en sorte de copier ces fichiers sur un autre ordinateur, que je désignerai par Bravo, qui peut appartenir ou non à la même personne qu'Alpha.

On va considérer que ces données sont d'une taille raisonnable pour les standards actuels.

Quelle est la façon la plus pratique de s'y prendre ?

En général, le plus pratique est de passer par une mémoire flash (ou « clef ») USB. Même si la plupart des ordinateurs sont connectés sur un réseau, c'est dire le triste état des logiciels et de leurs interfaces à notre époque.

Il n'y a pas grand chose à dire sur cette solution éprouvée. Supposons donc que, pour une raison ou pour une autre, par exemple à cause de la distance entre les deux ordinateurs ou les craintes de transmissions virales, cette solution ne soit pas acceptable.

La solution la plus pratique est généralement de passer par un serveur HTTP accessible en réseau (ce qui suppose donc que ces deux ordinateurs soient connectés à un réseau).

C'est (encore) dire le triste état de l'informatique actuelle, utiliser un protocole de transfert d'hyper-textes pour transférer des fichiers.

Ça doit plutôt bien fonctionner, vu qu'il y a un marché raisonnable pour faire précisément ça, entre DropBox, Google Drive, One, etc.

Qu'il faille faire intervenir un troisième ordinateur, disons Sierra, pourquoi pas, ce n'est pas pire qu'une mémoire flash ou qu'un fournisseur d'accès à internet. Mais qu'il faille faire intervenir une personne morale supplémentaire, avec un droit de regard direct sur mes fichiers, ça me gène un peu plus. Pour paraphraser Benjamin Bayart, qu'est-ce que mes données foutent sur pas-ma machine ?

J'ai donc entrepris d'écrire un serveur web à cet effet, que j'ai publié en logiciel libre, parce que tout le monde s'en fout éperdument et donc je n'ai aucun risque de le voir forké ou de me faire démonter publiquement. Le dépôt fossil n'est pas encore montrable, mais le miroir sur GitHub est tout à fait fonctionnel.

Il s'agit donc d'un serveur de fichiers publiquement accessible sur le grand 'ternet (et en réseau local, pour peu que l'on l'y déploie). Il est assez évident qu'un serveur de fichiers ouvert à tous les vents va rapidement être abusé, donc il faut trouver un moyen de le sécuriser, mais sans gêner les utilisateurs légitimes.

Ce dernier point exclut les systèmes de comptes et les autres identifications fortes : pour être utile, il faut que ce soit simple et efficace pour un utilisateur quelconque, qu'il contrôle Alpha ou Bravo. Il ne reste donc guère que l'utilisation d'un secret quelque part dans l'URL.

Comme l'utilisateur quelconque peut jouer le rôle d'Alpha, cela implique que techniquement, n'importe qui peut envoyer un fichier, sans aucun contrôle. Pour garder le contrôle, il ne me reste donc que la possibilité de cacher le lien de téléchargement d'un fichier envoyé.

En fait s'il fallait vraiment contrôler avant l'envoi, il resterait la possibilité de créer des quota, avec une identification dans l'URL avant de recevoir le formulaire HTML. Je finirai peut-être par y venir, mais ça implique une interface d'administration pour moi, soit par HTTP avec la complexité de distinguer les utilisateurs quelconque des administrateurs, soit par un autre moyen qui suppose que je ne sois pas coincée derrière un firewall idiot. Avec la difficulté supplémentaire de communiquer ce qui est valide au front-end qui accepte le formulaire avant de donner le contrôle à mon application.

Comment cacher le lien de téléchargement ? En incorporant un secret dans son URL, connu seulement de l'opérateur du serveur (c'est-à-dire moi). Mais sans utiliser d'informations trop profondément cachées dans le serveur, pour pouvoir calculer l'URL sans avoir besoin du serveur.

Quelque chose d'imprévisible modulé par un secret, ça fait immédiatement penser au HMAC. Mais pas un HMAC du fichier, parce que si j'avais le fichier, je n'aurais pas besoin qu'on me l'envoie. Donc plutôt un HMAC du hash du fichier, plus facile à faire parvenir par d'autres canaux.

Le hash du fichier sert en même temps à construire l'URL d'un rapport de téléchargement, aimablement fourni à l'envoyeur, pour qu'il puisse vérifier que l'envoi s'est bien passé en comparait les hash, et au recevoir pour lire commentaires et nom original.

Autre astuce : le HMAC se comporte en fait comme un répertoire, en servant le fichier quelque soit le suffixe, ce qui permet de donner un nom arbitraire (pas forcément le même qu'à l'envoi) au fichier reçu.

Enfin, mon expérience personnelle avec le partage de fichier en utilisant un répertoire servi par HTTP, est que les fichiers s'y accumule et que ce n'est pas toujours facile de retrouver lesquels peuvent être effacés. Donc avec ce serveur, en plus du commentaire qui aide à resituer le fichier, j'attache une date d'expiration, au delà de laquelle le fichier est effacé.

Mon instance est disponible sur upload.instinctive.eu, que je préfère ne pas lier pour éviter les robots pénibles qui n'auraient que faire de robots.txt. Attention, c'est très moche, je n'ai pas encore pris le temps de lui donner une apparence décente (mais c'est moins moche que la page de LibreSSL).


29/07/2014

code. grind. sleep. >> Les stats de PostgreSQL dans un tmpfs avec Proxmox

Tags:

Au ${BOULOT}, on utilise Proxmox pour virtualiser, et surtout des containers OpenVZ (pour les hypeux qui ne jurent que par lxc, c'était et c'est pas encore si sec que ça lxc, faut beaucoup enrober, et on n'a pas le temps). Les machines PostgreSQL se trouvent donc être des containers OpenVZ.

Pour soulager les disques de certains I/O, des fois ça aide de placer le répertoire de travail du stats collector, par défaut $PGDATA/pg_stat_tmp et configurable par le GUC stats_temp_directory sur un ramdisk.

Sauf que dans un container, le guest ne peut pas manipuler ses filesystems, on doit passer par l'hyperviseur. Dans le cas d'OpenVZ, on peut ajouter un programme sous le nom CTID.mount qui permet de monter, justement, un tmpfs. Ce fichier est à placer à coté du fichier de conf, dans /etc/vz/conf.

On decide alors de placer nos stats dans /var/lib/postgresql/tmpfs, un tmpfs en mémoire. On ajoute ces répertoires pour garder la hiérarchie classique des instances PostgreSQL sur Debian : 9.3/main/pg_stat_tmp.

On écrit donc le script shell suivant dans /etc/vz/conf/CTID.mount, ou CTID est le numéro du container :

#!/bin/sh
# Script de montage d'un tmpfs pour les stats de PostgreSQL

# If one of these files does not exist then something
# is really broken
[ -f /etc/vz/vz.conf ] || exit 1
[ -f $VE_CONFFILE ] || exit 1
# Source both files. Note the order is important.
. /etc/vz/vz.conf
. $VE_CONFFILE

mountpoint=/var/lib/postgresql/tmpfs
subdir=9.3/main/pg_stat_tmp
postgres_uid=104
postgres_gid=108
size=104857600 # 100 Mo

mkdir -p ${VE_ROOT}${mountpoint}
mount -t tmpfs -o size=${size},uid=${postgres_uid},gid=${postgres_gid},mode=0700 tmpfs ${VE_ROOT}${mountpoint}
mkdir -p ${VE_ROOT}${mountpoint}/${subdir}
chown -R ${postgres_uid}.${postgres_gid} ${VE_ROOT}${mountpoint}

Dans le script tout ce fait dans le context de l'hyperviseur, c'est pourquoi on utilise les uid/gid numériques de postgres dans le container pour que les permissions soient correctes dès le boot.

Enfin, il ne reste qu'à modifier le fichier postgresql.conf pour configurer stats_temp_directory :

stats_temp_directory = '/var/lib/postgresql/tmpfs/9.3/main/pg_stat_tmp'

On peut alors redémarrer le container sur l'hyperviseur :

# vzctl restart CTID

Et voir depuis le container le nouveau FS :

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/simfs      100G   28G   73G  28% /
tmpfs           100M   12K  100M   1% /var/lib/postgresql/tmpfs
tmpfs           410M   32K  410M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           820M     0  820M   0% /run/shm

28/07/2014

GCU-Squad! >> Xen modes, le retour

Par : pinpin
Tags:
EC2
Irc
Xen
aws
hvm
pv
pvh
pvhvm
virtualization

Parce que c’est bien joli tout ça, mais comment on sait quel mode un guest donné utilise, hein ?

http://www.brendangregg.com/blog/2014-05-09/xen-feature-detection.html proposé par Seb sur #GCU@freenode