BiBite a écrit 42 commentaires

J'ai cherché un peu mais rien vu.
Dommage, ça ferait une bonne alternative à Google Drive…

Manifestement ils n'utilisent pas d'outils libre pour la partie hébergement/diffusion…

Hello,

La séparation en sous-réseaux c'est pour isoler les conteneurs qui n'ont pas à communiquer entres eux?

Oui, exactement. Dans la plupart des tutos, les containers sont tous mis dans dans un même bridge (lxcbr0). Le problème, c'est qu'avec cette approche, il devient très difficile de contrôler le trafic entre les containers avec iptables/nftables.

J'ai donc préféré laisser chaque interface de chaque container (l'interface côté host) indépendante (i.e. hors quelconque bridge). Le host doit donc router les paquets, mais par contrôle exactement le trafic à autoriser/forwarder entre containers et l'interface LAN du serveur (192.168.3.21 dans ton schéma).

L'interface dummy cela sert à quoi?

J'avais envie d'avoir une IP "fixe" sur le host qui ne dépend pas du serveur/contexte d'utilisation. Ca me permet d'avoir un README plus simple (toujours la même IP dans les README de config. des containers) et des règles iptables/nftables qui ne dépendent pas pas de l'IP LAN (en tout cas, en ce qui concernent les règles du trafic interne entre containers/host). Toujours concernant iptables/nftables, ça me permet aussi plus facilement d'exposer des services du host aux containers sans les exposer au LAN (comme le rsyslog du host qui reçoit les logs des fails2ban des containers par exemple).

J'ai donc une interface "dummy" (ip link add $IFACENAME type dummy sur le host) grâce à laquelle je peux donner une IP supplémentaire au host, toujours la même: 10.0.0.254. Le rsyslog du host n'écoute que sur cette IP par exemple.

Bref, j'ai un autre README pour configurer la partie LXC host+containers que j'applique sur plusieurs serveurs. Cette IP 10.0.0.254 est une petite astuce que j'utilise pour me faciliter un peu les choses, mais ce n'est absolument pas nécessaire en soit :)

L'idée d'avoir un fail2ban dans chaque conteneur dédié à celui-ci me plaît parce que c'est quand on conçoit un conteneur qu'on sait le mieux comment le protéger.
Niveau optimisation avec autant des services qui tournent cela ne génère pas trop d'écriture disque et/ou de consommation de ressource?

Oui, c'est l'idée: chaque container sait ce qu'il fait tourner et sait le mieux comment protéger ses services. Ça rend aussi les containers plus autonomes: pas besoin de modifier les règles fail2ban du host à chaque ajout/suppression/modification de container.

C'est vrai que fail2ban n'est pas un modèle de sobriété. Mais je ne vois pas pourquoi ça consommerait plus de ressources de répartir les règles dans plusieurs fail2ban par rapport à tout concentrer dans une seul; enfin sauf pour la RAM car effectivement fail2ban a forcément un coût fixe qui ne dépend pas du nombre de règles qu'il gère. De plus rsyslog est un très optimisé et très sobre.

Et enfin, les logs générés par les rsyslog des containers et parsé par le fail2ban du host sont vraiment très petits (1 entrée par "attaque") et ne nécessite qu'une expression régulière très simple. Donc le travail fait "en double" par le fail2ban du host n'est pas très méchant.

Il n'y a pas d'intérêt à mettre le fail2ban global qui coupe les accès dans un conteneur séparé?

Si, probablement. Déjà, ça permettrai de protéger le host; surtout que fail2ban a besoin des droits root.

J'avais réfléchi à la question, mais je ne vois pas comment faire ça facilement:
- comment faire pour que ce fail2ban isolé puisse être au courant des "attaques" sur le host (ne serait-ce que pour le SSH qui tourne forcément, au moins, sur le host) ?
Ca n'aurait aucun intérêt à faire tourner un fail2ban comme sur les containers. Il serait forcément root pour avoir accès aux logs.
- comment faire pour que le fail2ban isolé puisse bloquer le trafic au niveau du host/autres containers ?
Le fail2ban isolé a son propre espace "network": les régles iptables/nftables ne s'appliquent qu'au container qui l’exécute et n'ont aucun effet sur le host/autres containers.

Je n'ai pas trouvé grand chose sur le sujet, mais je suis preneur de toutes les bonnes idées qui me permettraient de ne pas avoir de fail2ban sur le host :)

Hello,

j'ai un serveur Debian avec une configuration similaire:
- les containers LXC (LXC guests dans mon readme) ont chacun un sous réseau en 10.0.N.0/24, avec N > 1
- le Linux natifs (LXC host dans mon readme) a une IP LAN en 192.X.Y.Z et un sous réseau 10.0.0.0/24 avec l'ip 10.0.0.254 sur une interface "dummy".
- le traffic IP est routé entre les LXC guests/host/LAN et quelques règles iptables permettent de rediriger le traffic de l'IP LAN vers les containers + autoriser certains traffics entre les containers + masquerading éventuel

Chaque container fait tourner son fail2ban, avec ses règles/jails à lui; mais les fail2ban (et les rsyslog) dans les containers sont configurés pour ne rien faire à part générer les logs de détection d'intrusion et renvoyer ces logs vers le Linux natif/host.

Le host fait lui aussi tourner fail2ban (qui, lui, ban vraiment) en parsant les logs du hosts, mais aussi les logs générés par les fail2ban des containers.

De cette façon, les règles fail2ban sont définies dans les containers (i.e. au même endroit que les services qui tournent/à surveiller); mais les actions sont exécutés par le host, qui est le seul à pouvoir vraiment bloquer le traffic des attaquants. Bien sur, pour les containers derrière un reverse proxy web (par exemple), il faut prendre soin de configurer le reverse/front et le backend pour que ce soit l'IP du client/attaquant qui apparaisse dans les logs du container backend, et non pas l'IP du reverse proxy.

readme perso, à adapter pour son besoin :

# Purpose:
# Define filters/jails in each LXC guest; but delegate the actual IP blocking to the LXC host.
# Indeed, each LXC guest knows what services it exposes, and what logs/regex to watch.
# But IPs should be blocked at the LXC host level because some guests can't directly protect themselves (ex: those behind a reverse proxy).
#
# How it works:
# fail2ban, in LXC guests, is configured to do nothing (except logging any filter match, which is the default behaviour) :
# - the LXC guests default action is changed to a custom action file which does nothing
# - the logging destination is changed from direct file to syslog.
# Then, rsyslog is configured to forward logs generated by fail2ban to the LXC host.
# On the LXC host, rsyslog is configured to receive logs from LXC guests and store them to /var/log/fail2ban-remotes.log
# It's fail2ban is configured to monitor and block the IPs found in this file.


On LXC host
##############

# Install fail2ban
sudo apt-get install fail2ban

# Configure rsyslogd to receive and store Fail2ban logs from our LXC guests.
sudo vi /etc/rsyslog.d/fail2ban_server.conf
---
# Listen for fail2ban logs coming from LXC guests
# and save them in a specific file for our Fail2ban.

ruleset(name="f2b-remotes") {
        action(type="omfile" file="/var/log/fail2ban-remotes.log")
        stop
}

module(load="imtcp")
input(type="imtcp" Port="514" Address="10.0.0.254" ruleset="f2b-remotes")
---
sudo /etc/init.d/rsyslog restart

# Configure logrotate for the file /var/log/fail2ban-remotes.log
# now filled by rsyslogd
sudo vi /etc/logrotate.d/rsyslog_fail2ban_server
---
# Rotate Fail2ban logs coming from LXC guests
# Better rotate weekly rather than daily so that Fail2ban
# can have bantimes >= 24h

/var/log/fail2ban-remotes.log
{
        rotate 4
        weekly
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript
}
---

# Install fail2ban
sudo apt-get install fail2ban

# Unfortunately, the iptables-allports.conf action have the "filter" table hardcoded.
# Add this new action file so that with now have the table as a  parameter, allowing
# the creation of rules into the "raw" table.
# raw/PREROUTING is processed before filter/INPUT (packets for the host) and filter/FORWARD
# (packets for LXC Guests, or hosts behind the router). Using raw/PREROUTING let us
# filter both cases with a single rule.
sudo tee /etc/fai2ban/actions.d/iptables-allports-gfa.conf >/dev/null << "---EOF---"
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
# Modified: Yaroslav O. Halchenko <debian@onerussian.com>
#                       made active on all ports from original iptables.conf
#           GFA
#                       adapted from iptables-allports.conf, adding the <table>
#                       parameter
#
#

[INCLUDES]

before = iptables-common.conf


[Definition]

# Option:  actionstart
# Notes.:  command executed on demand at the first ban (or at the start of Fail2Ban if actionstart_on_demand is set to false).
# Values:  CMD
#
actionstart = <iptables> -t <table> -N f2b-<name>
              <iptables> -t <table> -A f2b-<name> -j <returntype>
              <iptables> -t <table> -I <chain> -p <protocol> -j f2b-<name>

# Option:  actionstop
# Notes.:  command executed at the stop of jail (or at the end of Fail2Ban)
# Values:  CMD
#
actionstop = <iptables> -t <table> -D <chain> -p <protocol> -j f2b-<name>
             <actionflush>
             <iptables> -t <table> -X f2b-<name>

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck = <iptables> -t <table> -n -L <chain> | grep -q 'f2b-<name>[ \t]'

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionban = <iptables> -t <table> -I f2b-<name> 1 -s <ip> -j <blocktype>

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionunban = <iptables> -t <table> -D f2b-<name> -s <ip> -j <blocktype>

[Init]

# GFA
# Should ideally be moved to iptables-common.conf
# ---
# Option:  table
# Notes    specifies the iptables table to which the Fail2Ban rules should be
#          added
# Values:  STRING  Default: filter
table = filter
---EOF---


# Change default action to iptables-allport via the "raw" table, "PREROUTING" chain
sudo tee /etc/fail2ban/jail.local >/dev/null << "---EOF---"
[DEFAULT]
action = iptables-allports-gfa[table=raw, chain=PREROUTING, protocol=all, blocktype=DROP]
---EOF---


# Create filter for remote fail2bans
sudo tee /etc/fail2ban/filter.d/fail2ban-remotes.conf >/dev/null << "---EOF---"
# Fail2Ban filter for remote fail2bans
#
# GFA
# Inpired from filter.d/recidive.conf
# Detect all <HOST> found by remote fail2ban instances.

[INCLUDES]
before = common.conf

[Definition]
failregex =  ^%(__prefix_line)s(?:\s*fail2ban\.filter\s*%(__pid_re)s?:\s+)?INFO\s+\[[^\]]*\]\s+Found\s+<HOST>\s

ignoreregex =
---EOF---


# Create jail for remote fail2bans
sudo tee /etc/fail2ban/jail.d/fail2ban-remotes.conf >/dev/null << "---EOF---"
[fail2ban-remotes]
enabled = yes
logpath  = /var/log/fail2ban-remotes.log
---EOF---
sudo systemctl restart fail2ban



On LXC guest
##############

# Install fail2ban
sudo apt-get install fail2ban

# Configure Fail2ban to output logs via syslog. Then, we will configure
# rsyslog to send them to the LXC host.
#
# The purpose is make them available to the LXC host fail2ban daemon so that
# the host can block attacks detected by the guests. This way, all guests
# fail2ban detections will be merged on the host, and the host can ban
# offending IPs for the itself and all routed hosts (guests, LAN).

# Configure rsyslog to forward Fail2ban logs to the LXC host
sudo vi /etc/rsyslog.d/fail2ban.conf
---
# GFA
# Send fail2ban logs to the LXC host so that the host
# can block bad IPs for us.
# Requires a modified fail2ban config:
# /etc/fail2ban/fail2ban.conf:logtarget = SYSLOG

if $programname startswith 'fail2ban' then {
        # Local logging
        # Don't forget to configure *logrotate* accordingly if uncommented.
        # If commented, fail2ban logs will still be available in /var/log/syslog files
        #action(type="omfile" file="/var/log/fail2ban-syslog.log")

        # Remote logging
        @@10.0.0.254
}
---
 sudo /etc/init.d/rsyslog restart

# Configure fail2ban to send logs over syslog
sudo vi /etc/fail2ban/fail2ban.local
---
# GFA

[Definition]
# Send logs over rsyslog so that rsyslog can send them to the LXC host
logtarget = SYSLOG
---
sudo /etc/init.d/fail2ban restart

# Stops logrotate to handle /var/log/fail2ban.log since this file
# is not created anymore.
sudo vi /etc/logrotate.d/fail2ban
---
# GFA:
# Fail2ban is configured to dispatch logs through syslog,
# so we don't need to logrotate this file anymore.

#/var/log/fail2ban.log {
#
#    weekly
#    rotate 4
#    compress
#
#    delaycompress
#    missingok
#    postrotate
#       fail2ban-client flushlogs 1>/dev/null
#    endscript
#
#    # If fail2ban runs as non-root it still needs to have write access
#    # to logfiles.
#    # create 640 fail2ban adm
#    create 640 root adm
#}
---
sudo rm -rf /var/log/fail2ban.log

# Create a do-nothing target. We just need to generate syslog found/ban entries.
# This is the host which is responsible for actually banning IPs.
sudo tee /etc/fail2ban/action.d/do-nothing.conf >/dev/null << "---EOF---"
# Fail2Ban configuration file
#
# GFA
# Adapted from the dummy.conf action
[Definition]
actionstart =
actionflush =
actionstop =
actioncheck =
actionban =
actionunban =
---EOF---

# Change default action to do-nothing.conf
sudo tee /etc/fail2ban/jail.local >/dev/null << "---EOF---"
[DEFAULT]
# Do nothing except logging offenders with "Found <ip>"
action = do-nothing

# Don't ban offenders to avoid polluting logs with
# "Ban/Unban/Ignore <ip>" entries...
# Didn't find a propre way to disable banning, so use these timings to ban
# if more than 10 tries in the same second.
maxretry = 10
bantime = 0
findtime = 0
---EOF---
sudo /etc/init.d/fail2ban restart

Je n'ai pas fini de le tester, il y a surement de petites coquilles qui trainent par-ci par-là :)

Hello,

oui, le wiki de Arch est pas mal ! Mais, globalement, c'est vrai qu'on trouve très peu d'infos sur LXC (encore pire depuis que LXD existe), et c'est bien dommage.

La syntaxe de /etc/subuid est la suivante:
<login>:<start_of_subuid_range>:<number_of_subuids_in_the_range>
Ce fichier permet de réserver des plages d'UIDs pour chaque user du système.
Source: man subuid et man subgid

Sur une Debian/Ubuntu, il semblerait que 65536 UIDs soient nécessaires pour les besoin du système: de 0 à 65535 inclus
Je n'ai pas trouvé de source propre, mais voici quelques indices :
- http://www.debianhelp.co.uk/usersid.htm
- /etc/passwd : le user nobody a l'UID 65534 (et on a envie d'arrondir à 65535 qui est 2¹⁶ - 1)

Donc, au minimum, on peut faire ça /etc/subuid :
ache:65536:65536

Le plus souvent, dans les tutos, on trouve ça :
ache:100000:65536
i.e. Les UIDs de 100000 (colonne 2) à 131071 inclus (65536 à 131071 nous font 65536 UIDs (colonne 3)) sont réservés pour le user "ache" (colonne 1).

Explications :
Le 1er UID réservable (colonne 2) doit être >= 65536 car on a vu que le 65535 est le dernier UIDs réservé et utilisé par le système. Souvent, ce 1er UID est arrondi à 100000 pour simplifier la lecture et la manipulation des UIDs. Dans cet exemple, on a donc une plage non utilisée de 65536 et 99999 inclus).
En colonne 3, il est conseillé de réservé au moins 65536 UIDs si on veut pouvoir "booter" un système complet Debian/Ubuntu dans un container.

Ensuite, avec ce /etc/subuid, le user "ache" peut créer un container en mappant le range d'UID "classique" qui va de 0 à 65535 (vu dans le container) sur 100000 à 131071 avec cette conf. LXC:
lxc.idmap = u 0 100000 65536

Ce qui signifie pour LXC: les UIDs qui commencent à 0 dans le container commencent à 100000 en dehors du container, et la taille de ce range est 65536 UIDs (0->65535 dans le container est 100000->131071 en dehors du container).
Source: man lxc.container.conf ou https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html

Et c'est tout pareil avec les GIDs.

Perso, j'ai laissé tomber la création de containers non privilégiés depuis des users non-root :
- les containers démarrés depuis un user non-root ne peuvent pas utiliser "lxc.start.auto" pour se faire démarrer au boot du serveur. Enfin, c'est possible, mais il faut se faire des units systemd à la main.
- comme pour les UIDs/GIDs, il faut réserver des interfaces réseau dans /etc/lxc/lxc-usernet pour que les users non-privilégiés pour lancer un container qui a accès au réseau
- d'après la doc. LXC, root peut aussi lancer des containers non privilégiés, qui, une fois lancés, n'ont pas plus de droits que ceux lancés par des users non-root.

Donc je lance mes containers LXC non-privilégies depuis root pour avoir les avantages des containers non privilégiés, sans les inconvénients des containers lancés depuis des users non-root :)
Mon /etc/subuid ressemble à ça:
root:100000:10000000

Ca me permet d'exécuter jusqu'à 100 containers isolés (oui, j'ai aussi arrondi la quantité d'UIDs à 100000 au lieu de 65536 par facilité) avec des confs. LXC qui suivent ce pattern:
container1:
lxc.idmap = u 0 100000 100000

container2:
lxc.idmap = u 0 200000 100000

etc…

Hello,

pour ma part, j'ai mis en place un bête CAPTCHA audio et je suis passé de 5~10 appels commerciaux par jour à 0 :)

En gros, pour chaque appel entrant, je fais écouter un message qui demande à l'appelant d'appuyer sur une touche de son clavier téléphonique pour confirmer que ce n'est pas un appel commercial.

Si appui touche, le numéro de téléphone de l'appelant est whitelisté pour lui éviter le CAPTCHA aux prochains appels, et mon téléphone sonne pour que je puisse prendre l'appel.
Sinon, je raccroche sans même faire sonner mon téléphone.

J'ai la chance d'avoir un FAI (K-Net) qui propose une offre téléphonique basée sur du SIP standard et ouvert. Il m'a suffit d'installer un Asterisk en coupure entre mon FAI et mon téléphone et de suivre ce genre de tuto (ouais, apparemment je n'étais le premier à avoir eu l'idée !)
https://huxtable.ca/posts/2019/05/05/asterisk-captcha.html

J'utilise l'application "E-mail" d'Android AOSP (LineageOS dans mon cas).
Elle est (un peu trop) simple, mais ça fait le boulot et c'est open source.

J'avais testé K9-Mail mais les réglages sont limites incompréhensibles.

+1 pour burp backup

Conception simple et robuste si le "protocole v1" et le mode "hardlink" sont utilisés:
- les fichiers sont stockés simplement, avec un dossier par host, puis un dossier par backup.
ex:
/var/spool/burp/workstation/0000753 2018-10-28 02:30:39
/var/spool/burp/workstation/0000754 2018-10-29 02:30:42
/var/spool/burp/workstation/0000755 2018-10-30 02:30:39
…
/var/spool/burp/dedibox/0000467 2018-10-29 02:30:39
/var/spool/burp/dedibox/0000468 2018-10-30 02:30:39
/var/spool/burp/dedibox/0000469 2018-11-03 02:30:38
…

Ca n'a l'air de rien, mais contrairement à beaucoup d'autres softs, ça permet très facilement d'analyser les backups, comprendre ce qui prend de la place. Ca permet aussi d'exposer facilement les backups via Samba ou autre.

Pour les fichiers qui ont été déplacés/renommés, burp est fourni avec "bedup" qui permet de chercher et remplacer toutes les copies d'un même fichier par un hardlink.

Enfin, le stockage est pérenne. Même si burp backup n'existe plus dans quelques années, les backups resteront toujours accessibles.

• Le client supporte aussi bien Linux que Windows (un seul soft pour tous ses backups). L'auteur explique qu'il est parti de Bacula qui supporte VSS (permet le backup "atomique" sous windows).

• backup rapide. Chez moi, le backup complet de ma machine windows prend environ 1 minute pour +100Go et +30k fichiers, HDD mécanique.

• intégrable/flexible. Par exemple, Burp propose d'exécuter des scripts pre/post backup. C'est très pratique pour préparer son backup (dump d'un base de donnée sur serveur par exemple) ou pour lancer un second backup offsite.

Tu veux parler du logiciel de sauvegarde restic ?

J'utilise Borg Backup pour le moment mais je dois dire que restic me fait de l'oeil.

restic, en tant que client, fonctionne aussi bien sous Linux que sous Windows. Il s'installe très rapidement car il est disponible sous forme d'un seul binaire compilé statiquement. Il a l'air assez rapide d'après ce que j'ai pu voir de mes (rapides) essais. Enfin, pour ne rien gâcher, l'auteur semble très sympa et très réactif.

Parmis les petits bémols, je me souviens que la configuration sous Windows était pénible avec le backend SSH (il faut un client Windows SSH bien configurée). Mais c'est certainement plus simple avec le backend rest-server dont tu parles.

J'ai des TP-LINK TL-WN722N, ça fonctionne bien sous Linux, y compris en mode monitor.

Regarde aussi du côté de select(), ça te permettra de de faire une tentative de lecture sur le port série sans rester bloquer indéfiniment aucun octet n'est dispo dans le buffer...

J'ai utilisé Postgresql pendant un temps et j'avais beaucoup apprécié les fonctionnalités et la rigueur du système.

Depuis, je suis revenu sur MySQL pour des raisons indépendantes de ma volonté. MySQL me donne l'impression d'un soft un peu 'sale' et pas terminé. La version 5 est plus rigoureuse que la série des 4.1.x, mais il y a toujours cette impression d'inachevé. Je pense notamment au (non) support des transactions imbriquées.

Combiné avec le côté 'pas propre' de la chose - ie. ouvrir une transaction dans une transaction provoque un commit de la transaction en cours et l'ouverture d'une nouvelle transaction sans aucun message d'erreur - c'est _impossible_ de faire des procédures stockées transactionnées. Ou alors on prend le risque de commiter la transaction en cours si l'utilisateur en avait ouvert une avant d'appeler la procédure. La conclusion, pour moi, c'est que les nouvelles fonctionnalités (procédures stockées, triggers, ...) de cette version 5 sont franchements limitées.

Bref, il reste encore du boulot à faire sur MySQL, mais il faut reconnaître une chose : le système de réplication Master -> (n) Slave est très pratique et n'a pas d'équivalent sur Postgresql. C'est très dommage, d'autant plus que Postgresql intègre un log des écritures dans la base (comme MySQL) et qu'il suffirait de pas grand chose pour rejouer ce log en temps réel sur un ou plusieurs replicats, à la manière de MySQL.

Alors OK, il y'a Slony qui permet de répliquer des bases Postgresql, je trouve le système un peu archaïque, peu sur et assez lourd (notamment si la structure de la base change de temps à autre).

Ca me fait penser que j'ai déjà eu le même genre de problème sur une carte mère Abit. J'étais pas en mode DOS pure.

=> J'ai suivi le manuel: une disquette avec un autoexec.bat qui fait le boulot de reflashage et ça a marché du premier coup.

Alors si ton lecteur CD semble encore reconnu, tente le coup !

Je vais être un peu hors sujet, mais est-ce que tu peux préciser ? J'utilise le système de réplication de MySQL 4.1 au boulot (oui... j'aurais bien aimé utiliser PostreSQL mais c'est un autre débat) et j'en suis assez content. Tant qu'il n'y a pas de panne de courant la réplication marche au poil.

Est-ce que ce sont les nouvelles fonctionnalités de MySQL 5 (triggers, procédures stockées) qui font que la réplication ne fonctionne plus si bien ?

Je suis assez d'accord avec reno. Il y'a quelques trucs non standards dans MySQL qui sont parfois très genants, en vrac:

- Tu fais un update du genre:
update table1 set result = 'OK' where val = '10';

avec MySQL, si tu as 10 tuples (lignes) avec result val = '10' et que tu as déjà 3 lignes avec result = 'OK', MySQL te dit qu'il a modifié 10 tuples...
Super chiant dans certaines applis pour vérifier que tu as bien modifié ce que tu voulais. Les autres BDD auraient retourner 10 lignes modifiées.

- Tu fais un update (encore) du genre:
update table1 set date = '2005-12-32';
MySQL accepte sans broncher, alors que la date n'est pas valide (32 décembre).

Idem si on essaye de mettre un chaine de 20 caractère dans un varchar(10), pas de problème... Sauf que du coup la chaîne est tronquée et tu ne t'en rends pas compte.

Bref, au moins avec postgres tu limite ce genre de mauvaise surprises...

Arghhh
Tu sais que normaliser un fichier audio est une opération destructrice (en gros, la qualité du son diminue, et tu ne peux pas revenir en arrière) ?

Quand j'étais en stage chez DS (y'a 1 an), CATIA était en cours de portage vers Linux, je suppose que le support Linux e devrait pas trop tarder !

Pas tout à fait..

D'après de texte de l'académie française que tu cites, "malgré qu'il en ait" n'est juste que s'il n'y a pas de complément après. Dans ce cas, "malgré qu'il en ait" a un sens particulier dans le langage soutenu qui signifie en gros "malgré ma colère" / "malgré mon dépit"

cf. les exemples:

"Je reconnais les mérites de mon rival, malgré que j’en aie. Malgré qu’il en ait, nous savons son secret. Elle ne put cacher son dépit, malgré qu’elle en eût"

Ah oui...
Je m'était "oui, moi je prend le .zip, jsuis pas une tafiolle". Mais euh bon... Je vais quand même tenter l'exé alors ^^

Quelqu'un a essayé de compiler QT 4.0 sous windows ?

J'avoue que je sèche un peu sur comment faire... Dans le fichier INSTALL ils disent juste de faire un ./configure suivi d'un nmake, mais le configure en question ne génère aucun makefile :/

Y'a bien un makefile QT qui existe, mais il me faudrait qmake pour compiler .. qmake et ses potes. Bref, c'est pas gagné.

Je crois qu'il règne une certaine confusion entre:
1 - un programme linké statiquement avec une lib
2- un programme linké dynamiquement avec une lib
3 - un programme qui n'a pas linké mais appel une (des) librairies dynamiquement au runtime.


Cas N° 1

Dans le premier cas, le programmeur inclut les headers de la lib qu'il veut utiliser (nom des fonctions + signature donc). Au moment de la compilation, le linker cherche les fonctions qui ne sont pas déjà dans le code link les bouts de codes externes dans un unique exécutable: au final, l'exécutable contient tous les bouts de codes externes auxquelles il fait appel (plus le code de l'éxécutable proprement, bien entendu ^^).

Il peut donc tourner sans que les librairies qui ont servit au moment du link soient présentes sur le système. L'inconvénient est que l'exécutable est plus gros et qu'il ne profite pas des mises à jour des librairies.



Cas N°2

Dans le deuxième cas, tout se passe comme dans le premier cas, sauf qu'on dit au linker de linker dynamiquement. Le linker ne va pas donc pas inclure les bouts de codes externes comme un gros sale, mais va indiquer dans l'exécutable que certaines fonctions ne sont pas présentes et que l'OS devra les chercher parmis les librairies dynamiques à sa disposition avant de lancer l'exécutable. Je précise que cette recherche se fait avant que l'exécutable se lance, donc pas besoin de faire des "tests intensifs" pour savoir si toutes les libs dont le soft a besoin sont là.

Dans ce cas, si le développeur utilise en interne une fonction qui a la même signature, le même nom et le même espace de nommage que le nom d'une fonction externe qu'il utilise également, ça ne passera pas. Mais l'erreur se produira au moment du link, et non pas lorsque l'utilisateur lancera l'exé.

Idem, si le système ne trouve pas la lib, en question, ou que la signature attendue dans la lib diffère, alors le système refusera de lancer l'exécutable nous dira qu'il n'est pas content parcequ'il n'arrive pas à trouver telle ou telle fonction dans la lib machin-truc.



Cas N°3

Enfin, il y a le 3ème cas. Le développeur utilise un appel système pour dire qu'il veut utiliser les fonction "toto" de la librairie "libmachin.so". Une fois compilé, il est impossible de savoir si l'exécutable fait appel à des librairies externes et encore mois de connaître le nom des ces fonctions (Bon, si le mec veut vraiment, il pourra, ne serait-ce qu'en décompilant le soft. Et je pense que c'est plus simple que de faire exécuter tous les chemins possibles du code ^^). C'est ce qui permet notamment de charger des plug'in à la volée, sans fermer/réouvrir le soft.

Si le système trouve la lib et la fonction au moment de l'exécution, alors tout se passe bien. Le programme a alors un pointeur de fonction (que le dév a pu appeler "toto_ext"), et s'il a déjà une fonction "toto", tout se passe bien puisque les deux n'ont pas le même nom dans le programme en question (sinon, ça n'aurait pas compilé).

Sinon, soit le dév. a prévu le coup et tout se passe bien (on peut imaginer que le soft exprime sont mécontentement et continue avec une solution de secours ou alors se ferme). Soit le dév. a fait ça de manière un peu sale et il va manipuler un pointeur NULL, ce qui devrait aboutir tôt ou tard à un seg fault mérité :)


PS: j'avoue que ce que je viens de raconter est basé sur mon expérience avec Windows et ses DLL, mais je suppose que c'est la même chose ou presque sous Linux.

Pour ceux qui s'empresserait de télécharger la dernière version en pensant ainsi se mettre à l'abri des failles de sécurités découvertes récemment, n'oubliez pas de faire un dump/restore de vous bases de données.

D'après ce que j'ai compris, ils ont changé certains droits par défaut dans les templates, et donc si vous ne faites pas de dump/restore, vous conserverez les droits par défaut de votre version précédente, et donc les failles de sécurités qui vont avec ^^.

Salut,

il me semble que apt-get, par défaut, conserve les fichiers de configuration. Si tu fais un simple

apt-get remove samba

alors, les fichiers de conf de samba restent (dans /etc/samba...). Mais ça ne signifie pas pour autant que samba n'a pas été désinstallé (pour ça, il faut que tu regardes si tu as toujours la binaires smb et nmb). Par contre, je ne comprends pas pourquoi un apt-get install samba ne remet pas les fichiers de configuration.

PS: Y'a pas d'épreuve d'orthographe pour ton BTS ?
PS2: il faut utiliser 'apt-get --purge remove samba' pour virer les fichier de conf en même temps que le reste.

Terrible. C'est exactement ce que je recherchais, merci !

C'est pas aussi souple que véritable accès au repository, mais ca permet quand même de voir toutes les modifs unes par unes qui ont été apportées au kernel ou à un fichier du kernel en particulier.

D'ailleurs, est-ce que M. tout-le-monde peut accéder au repository (en lecture, pour les lecture/écriture je suppose que non ^^), ou est-ce qu'il faut être parmis les dev. actifs du kernel ?

Enfin bon, sur les livebox, le WiFi est crypté en WEP, et la clef est différente pour chacune... Et c'est pas le cas de tous les modems hein.

Alors le mec, à part s'il partage sa connec avec ses voisins de palier, il risque pas grand chose en laissant le password par défaut.