Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
nijau a écrit :dans certains pays, des gens croupissent dans des geoles pour de simples écrits ou paroles
Oui parce qu'ils les diffusent ouvertement, en les diffusant cryptés cela aurait-il le même sens ?
Serait-ce la même lutte ?
smolski, il faut faire la distinction entre s'adresser aux peuples et ne pas laisser venir fouiner sur une machine et en plus pas de choco dans les geôles..
donc on va retrouver un ordinateur avec un disque et des données aléatoires et tu crois que personne ne va se poser de questions ?
quel linuxien n'as jamais fais dd if=/dev/urandom of=/dev/sda... avant de formater une partition, rien d'extraordinaire à ça.
C'est bien plus crédible que de refuser d'obtempérer à une perquisition comme tu le préconisais, tu crois pas ?
Maintenant, qu'est-ce que dans la vie est si important qu'il faille le dissimuler à donf ?
la vie ou rester en liberté justement, n'oublie pas que dans certains pays, des gens croupissent dans des geoles pour de simples écrits ou paroles.
Oui, s'ils ne trouvent pas de données faisant obstacles "à la manifestation de la vérité, à la sauvegarde des droits des parties ou lorsqu'elle présente un danger pour les personnes ou les biens", paie ton nombre de possibilités et d'arguments fumeux sur lesquels ils peuvent t'envoyer te faire voir.
c'est toi qui gère les données présentes sur ton disque pas moi.
@nikau: tu nous cites tes sources pour l'obligation de donner les clés de chiffrement ?
l’article 434-15-2 du code pénal punit de 3 ans de prison et 45 000 euros d’amende le fait, « pour quiconque ayant connaissance de la convention secrète de déchiffrement d’un moyen de cryptologie susceptible d’avoir été utilisé pour préparer, faciliter ou commettre un crime ou un délit, de refuser de remettre ladite convention aux autorités judiciaires ou de la mettre en oeuvre, sur les réquisitions de ces autorités »
voir article 434-15-2
https://www.legifrance.gouv.fr/affichCo … e=20100630
Des témoignages existent sur des abus, surtout depuis l'état d'urgence qui n'oblige plus l'autorisation d'un juge pour ce faire.
Déjà bien avant l'état d'urgence et le sera après aussi, il suffit d'être au mauvais endroit au mauvais moment et c'est la perquisition.
-le déni-plausible n'est en fait possible que si les données chiffrées ne font apparaître aucune différence avec des données aléatoires et c'est bien là que repose tout le fondement.
(header luks absent bien sûr)
-donner le passphrase ou keyfile de dé-chiffrement d'une partition luks visible aux autorités évitera les en-merdes assurés (la loi oblige de donner les clés) et ainsi la présence d'un programme comme cryptsetup est justifiée.
-on peut très bien camoufler par ailleurs un autre espace chiffré en plein milieu d'une partition classique ext4. (voir les périphériques de type loop pour ajuster un offset), si aucune différence n'est alors possible entre des données chiffrées et des données aléatoires, les autorités n'auront même pas à avoir connaissance d'un deni-plausible.
-question confort utilisation, on peut très bien automatiser avec un script, (script + keyfile pouvant être chiffrés dans une image)
-pour parfaire le tout, on peut très bien utiliser un virtualbox installé sur l'espace chiffré.
Des types appartenant au commun des mortels (donc pas forcément plus clair que les autres) avoir le droit de venir perquisitionner... Les supports informatiques restent finalement l'unique terrain ou on peut encore protéger avec un déni-plausible.
tu a utilisée ce tuto => https://debian-facile.org/doc:materiel: … ia:accueil
vers la fin tu a la section => Pilotes propriétaires legacy avec DKMS
oui et c'est justement depuis ça que j'ai une erreur rrmod avec nvidia_uvm, tans pis j'ignore cette erreur, j'ai ajouté nvidia_current dans /etc/modules et ça démarre bien ainsi.
merci à toi, je vais attendre au moins une semaine pour mettre ce post en résolu, pour l'instant les mise en veille et hibernation sont nickels.
edit: j'ai pas encore trouvé l'erreur rmmod de nvidia_uvm alors j'ai mis nvidia_current dans /etc/modules et ça fonctionne ainsi.
pour enlever le message de l acpi , il te faut installer le driver 304 => Your card is supported by the default drivers and legacy driver series 304.
avec des cartes anciennes il y a des soucis avec nouveau (selon le model )
le paquet s appelle xserver-xorg-video-nvidia-legacy-304xx (voir le tuto nvidia du wiki D_F pour la procédure) section legacy
ok merci, je vais regarder ça plus tard, ouf la mise en veille refonctionne, c'était surement le nomodeset qui perturbait ACPI, j'ai rebooter en mettant simplement cette option:
et il démarre normalement..
merci pour ton aide, je reprendrais plus tard avec le paquet xserver-xorg-video-nvidia-legacy-304, là je fais le break, depuis 13h52 que je suis là-dessus...
mais j'ai toujours le warning dans kern.log
toutefois pour l'instant je laisse comme cela, et je tiens au courant si la sortie de veille rebloque...ce n'est pas systématique..
dans kern.log on peut y voir ces lignes, conflit plage mémoire PMBA et GPIO, existe t'il une technique particulière pour résoudre ce problème ACPI ? je n'avais pas ce problème sous Wheezy.
cher administrateur,
je comprends et respecte ton commentaire.
en venant ici je pensai trouvé ce que je n'avais pas pu trouver ailleurs. Je tiens à te rassurer, je sais lire et je sais comprendre un tuto. Le grand problème est que tous ces tutos sont rédigés par des bénévoles qui ont compris ce qu'il essaient d'expliquer mais ne pensent pas forcement que la personne qui doit le lire ne le consulte pas par hasard. Je remercie au passage tous ceux qui prennent sur leur temps pour essayer de partager leur savoir.
Je tenais simplement à faire part d'un constat. Il est plus difficile de faire comprendre ce que l'on sait que d'apprendre ce que l'on ne sait pas.
Si je suis passé sur Linux, ce n'est pas pour vous embêter mais pour essayer de comprendre comment cela fonctionne, même si à mon âge cela n'est pas toujours facile.
Merci encore à ceux qui ont tenté de m'aider
bonjour, la communauté Linux n'oublie absolument personne, tu peux faire intervenir un parrain de ton secteur chez toi, cela ne coûtera qu'un petit café ou choco...: http://www.parrain-linux.com/annuaire.php
edit: Je viens à l'instant d'apprendre sur ce site parrain le décès du fondateur Debian, Ian Murdock, il avait 42 ans https://fr.wikipedia.org/wiki/Ian_Murdock
Merci à lui pour cette distribution Debian.
nikau a écrit :smolski a écrit :Dans les tutos df pour le ssh :
Le ssh pas à pas.
Puis :
partage de fichiers sécurisé
ben voilà tout y est ! (ou presque, il faudrait rajouter la ligne sshfs avec authenfication par clé)le dossier Partage reste désespérément vide!
hum.....pas de message d'erreur lors de la commande sshfs ?
que raconte mount ?
chez moi j'ai:nykau@192.168.0.104:// on /home/nykau/partage type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
tu veux dire quoi?
je trouve où ce message?
tu tapes mount, si tu ne vois pas cette ligne alors ça veut dire que la commande sshfs n'a pas fonctionné, ce qui explique pourquoi le répertoire partage reste vide, c'est pour cela que je t'avais demandé s'il y avait un message d'erreur ? après la commande sshfs,
tu devrais prendre les choses méthodiquement l'une après l'autre:
1 d'abord tu vérifie que ssh fonctionne bien : https://debian-facile.org/doc:reseau:ssh
ssh user@serveur (résultat ? indique les retours et non pas tes interprétations sinon personne ne pourra t'aider)
s'il ne fonctionne pas donne le contenu du fichier /etc/ssh/sshd_config du serveur et toujours sur le serveur:
ps -aux | grep ssh
2 ensuite tu reprends sshfs: https://debian-facile.org/doc:reseau:ssh:sshfs
sshfs utilisateur@serveur:// /home/user/partage/ (résultat, indique si message d'erreur)
Dans les tutos df pour le ssh :
Le ssh pas à pas.
Puis :
partage de fichiers sécurisé
ben voilà tout y est ! (ou presque, il faudrait rajouter la ligne sshfs avec authenfication par clé)
le dossier Partage reste désespérément vide!
hum.....pas de message d'erreur lors de la commande sshfs ?
que raconte mount ?
chez moi j'ai:
le montage sshfs a déjà été tester sur les deux machines équipées de la même distribution sans résultat.
comme je le disais plus haut, il me faudrait un tuto bien élaboré de A à Z
Je vous remercie tous pour vos conseils mais ils ne sont pas livrés avec des explications claires.
Installer ceci ou installer cela, je l'ai déjà fait mais sans résultat car les tutos partaient sur des configurations bien précises mais non indiquées, soit ils ne correspondaient plus à la nouvelle version installée,
etc.
Je ne suis pas fan de W$ et c"est bien pour cela que je passe à Linux, mais il faut avouer que cliquer sur un dossier et cocher "partager", cela a bien des avantages!
comment ça sans résultat... ssh est vraiment élémentaire, les tutos ne manquent pas pour configurer le fichier sshd_config
machine serveur: ssh
machine client : sshfs
mkdir /home/user/partage
sshfs user@serveur:// /home/user/partage/ -p 22
terminé, ouvrir gestionnaire de fichier --> dans /home/user/partage... (voir aussi sshfs dans fstab pour le montage automatique au démarrage)
si authentification avec clé:
sshfs user@serveur:// /home/user/partage/ -p 22 -o IdentityFile=/home/user/.ssh/clé
démontage: fusermount -u /home/user/partage
merci pour ton aide vv222,
mais comme je le disais plus haut, je voudrais pouvoir travailler sur mes fichiers sans avoir à les télécharger.
je vais voir du coté des serveurs médias, peut être que là je trouverais ce que je cherche
Dance ce cas, un montage sshfs depuis linux ou dokan-sshfs depuis un Windows, https://github.com/dokan-dev/dokany/releases
(les dossiers distants seront vus comme les autres avec les gestionnaire de fichier et exploitables en mutimédia et autre sans les télécharger, dans la limite de ta vitesse de connexion réseau)
envoyer dans un fichier les process..
et consulter mono.log
exemple voir s'il ne consulte pas les pages marques de iceweasel
grep bookmarks mono.log ou grep mozilla mono.log
il ne va que dans .config/.mono /home/user/.Private et /usr/share/.mono
alors il est propre, pas besoin d'apparmor pour cette application.
killer ensuite le pid de strace sinon mono.log va prendre de l'espace
Bonjour
J'aurais souhaité avoir votre avis sur la façon d'installer les applications Web sur vos serveurs Debian. La question me vient de la récente installation sur mon serveur de l'application webmail Roundcube. J'ai gentiment installé ça avec apt-get mon serveur encore sous Wheezy. Or, je m'aperçois qu'il s'agit de la version 0.7, la version 0.9 est dans les Backports Wheezy. Me projetant dans une future mise à jour vers Jessie, je découvre que le paquet n'y est pas présent.
J'avais eu la même problématique avec Owncloud, dont il n'existait qu'une version antédiluvienne dans Wheezy. Je l'ai donc installé via les sources. Une version plus récente a ensuite été intégrée dans les Backports, puis supprimé pour des raison de failles de sécurité.
Bref, compte tenu de la volatilité de ce genre d'application et des considérations de sécurité, je me demande s'il ne vaut mieux pas les installer directement depuis les sources ou des dépôts tiers bien maintenus (c'est ce qui est recommandé dans la doc de Owncloud) plutôt que via les dépôts officiels Debian.
Qu'en pensez-vous ?
Salut, avec la version 0.9 de roundcube, mon navigateur iceweasel 31.7.0 est incompatible, est le cas pour toi aussi ? 
edit: j'ai vidé le cache du navigateur et c'est ok avec la version 0.9 de roundcube.
warning: s72-38-252-2.static.datacom.cgocable.net[72.38.252.2]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
Ce message est typique avec une mauvaise authentification smtp depuis un client, j'ai déjà eu ce message du à une mauvaise config de thunderbird (icedove)
le message est clair: pas d'authentication SASL
si tu tapes echo -n "Password:" | base64 dans le terminal cela te renvois UGFzc3dvcmQ6 ce qui veut dire que tu as un identifiant ou un "password" dans ta config php qui peut être non interprété, tu peux aussi avoir ce message d'erreur si dans une configuration client smtp le nom utilisateur pour une authentification SASL est intitulé "user" au lieu de "user@domain".
Il faut donner plus de détails sur la configuration (postfix..)
et aussi penser à tester le SASL du serveur, exemple: testsaslauthd -u user@domain -p password qui doit retourner 0: OK "Success.
