PLuG a écrit 1006 commentaires

Ce que j'essayait de dire, c'est que le problème ne doit pas être traité au niveau technique, sinon effectivement c'est sans fin.
Il faut que l'entreprise sache eduquer (expliquer pourquoi les choses sont interdites) et communiquent régulièrement vers les employés. Il faut aussi que la direction ait le courage de ses décisions et que les personnes qui ne respectent pas la règle soient durement sanctionnées.
Quand la règle et la sanction est connue, les personnes n'enfreignent plus la règle (surtout pour bosser), elles font *enfin* remonter leur besoin au service informatique (au lieu d'inventer des astuces tordues et dangereuses ...)

Sinon des méthodes techniques y'en a pour les chats aussi, par exemple un proxy qui fait une sorte de man-in-the-middle pour vérifier le contenu de ce qui passe sur le port 443. mais y'a pas que le port 443 qui passe, y'a aussi des tunnels qui fonctionnent avec des requêtes HTTP (sans ssl)... il n'y aura jamais de solution technique définitive (sauf a couper le web ... et encore, les employés sont prêt a apporter des modems au boulot ...)

La méthode la plus simple: éducation des employés et charte informatique qui interdit ce genre de pratiques. Ensuite une seule porte de sortie du réseau (un proxy) simple à auditer...
Normalement la personne qui "n'a pas compris" lors des explications initiales ne récidive pas.

Ahhh ! Que c'est bon d'être vieux !...

ah non, ça c'est être jeune !
sinon que dire de ceux qui installaient la SLS en une cinquantaine de disquettes dans le début des années 90, avec un noyau version 0.98 ?

Quand on se lance sur du iSCSI c'est pour utiliser un SAN sans passer par la case couteuse FC (fiber channel, de la fibre optique et des switchs dédiés très chers). C'est donc en utilisant un réseau ethernet taillé pour le iSCSI avec au moins 1Gb/s de bande passante garantie (swicthée ou dédiée) par exemple. En général le SAN en face est *bien* plus rapide que les disques locaux.

Mais tu as raison, il faut initialiser la machine avant qu'elle puisse rechercher un drive iSCSI sur le réseau. Soit le /boot est en local, soit la machine utilise un boot PXE sur le réseau pour télécharger un ramdisk suffisant.... je ne sais pas comment RedHat le fait mais y'a des solutions.

la version executable de virtualbox avec la license pas trop restrictive permet de mapper les ports USB. (La version opensource ne le permet pas il me semble).

les tomtom utilisent le driver USB mass storage standard ... aucun problème pour mettre a jour les données de position de radar.
par contre pour mettre a jour le firmware je ne sais pas faire via linux, et le soft tomtom ne marche pas sous wine ... (j'ai un XP dans un virtualbox pour ça)

moi je prefere la version anglaise parce que les livres d'info en français c'est pas toujours super bien traduit. Je ne savais pas qu'en plus ils etaient moins chers.

mon fichier etait un fichier de log (unison.log) et je pense que qule-que-soit le fichier ce serait bien de récupérer sous le nom d'origine :-)

j'ai envoyé un fichier, mais au download il me le renomme (avec le hash utilisé pour le stockage ...)
ce serait bien que le fichier garde son nom dans l'opération :-)

C'est ma fois assez vrai ...
Les applications sont en général paramètrables pour leur expliquer ou chercher les informations dans l'annuaire. Le stockage du mot de passe est quelques fois contourné par les applications qui tentent tout simplement de s'authentifier sur l'annuaire lui même (et qui ne dépendent donc pas du format de stockage du mot de passe).

Le truc c'est de bien différencier SSO (single sign on) et ldap.
La question du mot de passe centralisé c'est plutot ldap, SSO c'est le fait de se logguer une seule fois pour toutes les applications. Souvent les 2 sont mélangées dans les solutions et dans les têtes.

Pour ce qui est de la création des comptes dans les applications, en général on crée un schema ldap avec un user et un mot de passe, puis on place ce user dans des groupes d'utilisateurs de chaque application (ou on leur affecte des attributs equivalents ...). Bref, l'application cherche d'abord l'appartenance a un groupe dans l'annuaire pour vérifier que ce user a bien le droit d'utiliser cette application, puis elle tente un logon sur l'annuaire avec le password de l'utilisateur. Normalement ce logon ne donne AUCUN droit de modification de l'annuaire, voire meme pas la consultation, c'est juste pour valider le password.

en pratique je suis d'accord, il faut etre payé pour aller vers LDAP, et ce genre d'annuaire est une bénédiction dans une grande entreprise, a la maison c'est plus pour apprendre a quoi cela ressemble :-)

Interêt du ldap en entreprise ?
- le provisionning: quand un type est embauché on crée de facto son compte mail, windows (pardon linux), ...
- quand un type est viré ou arrive en fin de contrat, sa suppression de l'annuaire invalide d'un seul coup tous les logons dans toutes les applications.
- ...

interet pour l'utilisateur: mot de passe unique
desavantage: mot de passe unique (il suffit d'une application mal foutue pour leaker le mot de passe qui donne l'entrée sur une autre appli beaucoup plus sensible). Pour cela preferer les methodes a la tokenID qui permettent de centraliser *aussi* la partie sensible qui manipule les mots de passe... mais c'est aussi un SSO :-)

bon j'espère que je t'ai pas saoulé :-)

exact, c'est l'outil que tu cherches, unison est fait POUR CA.

le support c'est une question d'expérience.

la mienne:
- un bug dans DB2, bloquant pour la prod => delai de solution du support: 9 mois !! si on avait eu les sources, on aurait regardé nous même ou payé quelqu'un !!
- un bug sur AIX 5.2 pour utiliser du CIFS. reconnu par le support, prétendu corrigé uniquement en 5.3. :-( pas grave, on teste en 5.3, a ben non le bug est toujours vivant. réponse du support: ne sera pas corrigé.

et des expériences comme ça j'en ai plein avec IBM.
Donc oui, pour faire payer le support ils sont forts, mais pour aider ... c'est moins sur !

Avec l'opensource, on corrige dans la plupart des cas nos problèmes (quelques patchs kernel (pout CIFS d'ailleur), mais aussi squid, des modules perl ...) et dans la plupart des cas du *vrai* support quand on arrive a joindre le bon forum/la bonne personne. ça fait chaud au coeur de voir que Alan Cox répond directement pour proposer un patch sur un problème de driver par exemple....

comme quoi c'est vraiment une question d'expérience, mais moi je ne conseille pas le support payant IBM (ni redhat mais c'est une autre histoire).

Ben avez vous changé de carte SCSI ? parce que la carte qui merde, ls FS en read-only (aussi probablement suite a un probleme detecté par le kernel), ...
ça fait envie de changer le matériel.

bon ça ne répond pas a ta question, mais il suffit d'une carte défaillante, de mémoire défaillante, de driver défaillant ... c'est le monde du PC. Essaie un autre PC :-)

De plus le Xserie n'est pas vraiment un serveur dixit IBM lui même. Ils le vendent a Lenovo comme les laptop d'ailleurs.... pour se concentrer sur les blades qui *eux* devraient profiter du serieux de la gamme serveurs ... on verra bien !

- AIX 6 n'est vraiment interessant que sur les P6 ... sortez vos chequiers...
- Ce truc de mobilité de machine virtuelle existe dans xen depuis longtemps ...
et en plus même si c'est *beau* je ne vois pas l'interet (en tout cas pour moi).
Jem'explique: j'ai deux salle serveur, et des serveurs AIX en HACMP (un node dans chaque salle). Le truc "mobility" ne m'affrnachis pas du tout d'HACMP (ça ne marche pas pour la haute dispo, si un node plante => pas de mobility, c'est utilisable sur un switch *volontaire*). Un switch volontaire donc, par exemple pour faire une maintenance. D'experience ça pourrait etre cool de mettre a jour AIX ... a ben non justement, AIX il bascule avec l'appli, il fait partie de la partition "mobile", donc pour la maintenance ce sera plutot HACMP qui va nous aider ...
Conclusion: c'est beau mais ça ne peux servir que pour mettre à jour un firmware sur le P6 en dessous ... pas super fréquent !! et en plus ça n'affranchis pas de HACMP qui lui permettait de patcher le firwmare du matos, AIX, l'application elle même ...
Si vous savez A QUOI CA SERT EN VRAI je veux bien des explications :-)

(et ne me racontez pas que je vais équilibrer la charge avec ça, de toutes façons il faut deux P6 et il faut que la charge totale puisse tourner sur un seul de ces P6 sinon il n'y a plus de haute dispo en deux salles).

C' est une question d'expérience visiblement. Où je suis on remplace massivement les machines AIX par des Linux.
Pourquoi ?
Parce que le cout de la maintenance annuelle des Pseries est supérieur à l'investissement necessaire en hardware Intel, qui de surcroit est plus performant !!!

Linux, sur un laptop, on y touche tous les jours et on a des soucis (comme les windows perso), mais un linux qui fait tourner Oracle, on ne passe que les patchs sécurité et on a zero soucis .... comme AIX mais en plus performant et moins cher.


De plus de base AIX, c'est du ksh moche, il faut ajouter des packages opensource RPM si on veut un peu d'outils modernes (un vrai VIM ? un vrai openssh ?, un vrai BASH ? ...)
enfin, chacun vois midi a sa porte :-)

Je suis d'accord avec toi, mais souvent la competence applicative n'est pas chez les DBA, qui en plus sont moins nombreux que les développeurs (et plus chers).
Enfin techniquement, mettre les fonctions applicatives dans les bases de données fini par bouffer de la performance sur la DB et les licenses (ok sur les DB commerciales ...) se paient au nombre de cores utilisés sur le serveur de DB...
J'ajoute que pour le stockage, multiplier les serveurs de DB coute aussi pas mal de fric.

Donc que faire ?
Utiliser la fameuse mode du n-tiers, et mettre un front-end java sur un serveur applicatif pour heberger le code applicatif sous forme de fonctions, publiée en SOAP par exemple.
Ces fonctions SOAP concentrent les appels aux DB (donc y'en a pas partout dans toutes les applis), le SOAP c'est gratuit (java + tomcat / jboss), et cela permet (comme les proc stockées) de rendre les fonctions disponibles pour toutes les applis de l'entreprise.

En bonus, SOAP est un protocole normalisé et disponible sur toutes les plateformes, dans tous les langages (pas la peine de déployer des connecteurs JDBC/ODBC/....)

Mais je suis d'accord avec toi, les proc stockées c'est bien, y'a juste des contrainte en entreprise qui font que d'autres solutions peuvent être préférées.

J'ai aussi un E61, c'est vrai qu'il n'est pas très rapide, mais je trouve que tu exagère un peu. Le problème c'est surtout la mémoire, si tu n'arrete pas les applications et que tu les laisse toutes tourner en parallele ça fini peut être par être aussi lent que tu le dis ...

Le clavier est vraiment pratique (azerty), mon E61 vient de chez orange, et en utilisant un petit soft téléchargeable sur le Net, on peut reprogrammer son "product code" et le mettre a jour avec le *vrai* firmware de chez nokia, interface bien plus agréable que celle d'orange, et surtout beaucoup moins de bugs que le firmware made-in-FT.

Pour la synchro mail, j'utilise un produit acheté par mon employeur. Ce produit c'est intellisync, capable de synchroniser les mails+agendas avec LotusNotes par exemple. Mais de base y'a déjà de quoi se connecter a son mail pop/imap.

Il y a plein de softs pour Synbian, comme googlemail ou googlemap par exemple ...

Au final, le E61 n'est pas parfait (soudimentionné en ram et cpu), mais il est très pratique.
Les défauts a mon sens:
- la fragilité du chargeur 5V/1A fourni (mais embout compatible fourni en standard pour utiliser un autre chargeur)
- la durée de la batterie en mode WiFi ou 3G, qui demande de recharger le téléphone tous les soirs.

effectivement un jour le dimanche (et le samedi) seront des jours comme les autres ... ben ça me parait normal à moi.

Quelle est la différence ? Aujourd'hui la différence c'est que les autres ne travaillent pas le dimanche et que du coup celui qui bosse ce jour la ne peut pas glander en famille avec les autres.

Quand les gens auront 2 jours par semaine (n'importe lesquels) de repos et que les 7 jours seront payés de la même manière, y'aura moins de problèmes puisque ... le dimanche sera un jour comme les autres :-)

PS: mon message s'adressait a toi directement pour reprendre le "style" du message précedent, mais effectivement non je ne te connais pas, et je ne t'en veux pas spécialement ... c'est un exercice de style.

Exactement, c'est l'individualisme qui triomphe... et le tiens aussi.
A oui tu t'en fou que les autres ne puissent pas faire leurs courses parce qu'ils bossent du lundi au vendredi toutes les semaines. Rien a carrer que les autres soient obligés de poser des congés pour faire la moindre démarche administrative, faire la révision de la voiture, ... ou aller chercher un recommandé à la poste.
Z'ont qu'a faire comme toi, avoir un lundi sur deux à la maison ! na.

Pour les autres, c'est pratique les administrations/garages/... TOUT ouvert le samedi et le dimanche, parce qu'en semaine ON BOSSE NOUS :-)

on peut activer le chiffrement (ssl) sans avoir de certificat ?
je pense que la plupart des sites autosignés veulent activer la crypto.

oui le E61, comme j'écrit plus haut avec le soft INTELLISYNC (racheté par nokia) ça marche très bien pour de la synchro mail + calendar + carnet adresse ... et sans serveur centralisé.

Bon c'est pas libre, sur ce site ça va moinsser quand même :-)

NOKIA a racheté il n'y a pas longtemp INTELLISYNC, un logiciel qui permet de pousser les mail (mode push) façon blackberry mais les contraintes de sécurité.

=> on installe le serveur dans l'entreprise, et on ne passe pas par un serveur blackberry en angleterre.
=> cela marche avec tous les smartphone ou presque (windows mobile, symbian, ...)

Donc non Blackberry n'est plus incontournable, les contrainte de sécurité on amené les concurrents a proposer autre chose (mais peut-etre un peu tardivement).

Pourquoi NFS ????

rsync s'utilise a travers le reseau si tu le lance en daemon coté serveur web, et dans ce cas rsync ne fera transiter que les datas modifiées (copie incrémentale) alors que si rsync accede au serveur a travers NFS il devra lire a travers le reseau le fichier complet pour trouver quels morceaux synchroniser ....

rsync est une bonne solution, mais ne rajoute pas de NFS au milieu.

réseaux standards ouverts tels que Jabber/XMPP et IRC ou encore SILC ou Zephyr, mais aussi aux réseaux propriétaires tels que MSN/WLM, AIM/ICQ, Gadu-gadu, Yahoo!Messenger ou Lotus SameTime.

IBM a passé Sametime en XMPP depuis pas mal de temps, d'après google. Donc c'est une imprecision dans la news non ?

Par ailleurs, quelqu'un a t'il de l'expérience sur la liaison entre Sametime et d'autres serveurs Jabber ??

en fait nous aussi on a des IP fixes en fonction de la MAC (pour certaines machines) mais cela ne force en rien a relancer le DHCP a chaque modif car :

au début la machine est inconnue, le DHCP lui donne une IP (pas fixe mais constante puisqu'il n'y a pas de raison qu'elle change)
au prochain redémarrage, elle devient fixe pour de vrai :-)

la contrainte c'est que l'ip est définie par le serveur DHCP mais elle est bien fixe.

nous relançons le service dhcp 2 fois par jour (cron) et a la demande avec un petit bouton dans l'appli web (pour les modif de PXE c'est necessaire si on ne veut pas attendre le cron ...)