Reprise du message précédent :

 
Ah ben forcément....  Checker les mails depuis le serveur ET EN PLUS ouvrir des pièces jointes dessus EN ADMIN    
 
C'est comme si je faisais du torrent depuis mes 'nux de prod
 
edit : ok explication lue

oui et oui

nos appli ont besoin de word et pdf reader  
et l'appli ne tourne que si c'est une session admin  

par contre c'est du serveur dedié ( rack sans ecran )avec personne qui bosse dessus . on sais toujours pas comment c'est entré mais c'est pas un mail ouvert depuis le poste c'est pas possible

Surtout à 3h du mat, c'est pas un peu bizarre ?

Le serveur n'était il pas déjà compromis ?

possible  
c'est pas moi qui m'en occupe  
le plus drole c'est de voir le presta en mode      
le client presque a se pendre    
le collègue qui doit s'occuper de ca qui as vu son week end partir en fumé  

Le cryptolocker verifie s'il tourne sous une session d'admin,
et il a un comportement different, il peut net pas s'executer tout de suite.
Il est intelligent.

Avoir une session admin obligatoire c'est comment dire bullshit.
Acceder à un fichier %systemroot% , local machine / program file

il faut juste faire chier l'editeur pour savoir comment il code.

Et ouvrir en modification uniquement les parties dont le programme est codé comme un pied pour modifier des fichiers systèmes.
 

J'ai vu un programme IHM , que si on changait le libellé d'un bouton pour appeler un programme, le nom du bouton devait etre le nom du repertoire . Chapeau bas (machine de + 80 000 € )

 
Perso, chez moi ça passe pas.
 
Certains m’appellent Mordac, mais rien à braire.
 
Pour les badges d'accès, facilities voulait un soft qui nécéssite les droits admin sur un serveur + quelques redirections de ports. (pour un projet qu'ils ont lancé sans me consulter, forcément)
 
ça a été non à tout.  
 
Ils m'en veulent pas mal et me traitent de tout les noms chaque fois qu'ils doivent faire venir le presta sur site pour créer des nouveaux utilisateurs, mais je tiens bon. Et ce genre de retour ici ne va faire que me conforter dans mes positions.

Moi je n'ouvre que ce qu'il y a besoin . modification dans telle clef sur le local machine à tout le monde, modification du programme toto dans program files

Faut pas être non plus intrensigeant, dire juste que les mecs codent comme à la préhistoire (xp)
et que maintenant il faut respecter les regles.

un programme c'est dans program files,
le parametrage n'a rien à foutre dedans

mais session admin c'est niet ^^

Il y a des softs qui nécéssitent les droits admins pour d'autres raisons qu'écrire dans program files, c'est là tout le problème. Ouvrir des droits d'écriture peut ne pas suffire. Un mec qui code dégueulasse, ça peut aller loin (ecriture dans le bdr, ouverture de ports/ressources en mode exculsif, ecriture dans c:\windows.. c'est sans limite)

 
Pour moi c'est incompréhensible que les grosses distros aient pas fait un alias de base avec --preserve-root (et idéalement "one-file-system" pour pas péter les montages externes). Bref, ya des solutions qui marchent bien

Mes préférés dans le genre ce sont les softs qui n'ont au final pas besoin de grand chose de plus que d'écrire dans leur dossier ou autre truc facilement contournable, mais qui ont codé en dur des checks qui bloquent le lancement du soft s'ils voient l'user est pas en admin ou que l'UAC est activé  

 
ça crierait au scandale "on nous enleve notre liberté"; "je veux pas que Shuttleworth décide à ma place ce qui est bon pour moi ou pas" et tous les autres trucs qu'on lit chaque fois que MS renforce un peu la sécurité sur Windows.  

 
Si c'est juste un alias dans le bashrc, ça fait pas grand chose. Contrairement au monde MS, ici tu as le choix d'utiliser le truc ou pas

nos devs codent comme des gros gros dégueulasses    
j'ai envie de me pendre environ deux fois par jours      
 
exemples en vrac :  
et que je te colle un dossier a la racine de c  
et que je te connecte a la base mysql en ROOT depuis les logiciels clients, ( sans front end, sans sécurité ni rien ).. direct en base  
et que je te stock le chemin d’accès a la base ( IP/port/nom de base/ login + password ) en clair dans un .ini sur c
 
comment dire ... rien qu'avec ca il y as de quoi virer un dev pour faute dans certaines boites  

Change de boite

 
Ca j'en ai 3/4 dans la boutique, .ini dans le systemroot
 
Mais le cas de polo jamais rencontré, le check si droit admin avant de lancer, c'est pas mal. Car dans 90% des cas c'est des écritures à des endroits pas tres catholique.  
 
Et j'adore quand on me dit:  
- vous avez activé UAC , cela ne se fait plus
- Ah bon ? Vous etes sur, il est la car le programme fait quelque chose qui est interdit et dangeureux pour le systeme, pouvez vous me dire ce que fait votre programme svp.
- Euh, faut que j'appelle mon support car je ne sais pas.
- Ok, je veux bien lancer l'install en admin, mais apres le users est bridé, donc dite moi quoi ouvrir sur le poste.
 

si tu me trouve un poste sur Bordeaux/Mérignac qui soit moins sous payé qu'ici, ca sera avec plaisir  
les opportunités manquent cruellement en ce moment

Sacrée histoire quand même

J'ai aussi l'éditeur qui m'a fait le coup. Suite à la migration de leur appli, on ne peut plus se connecter aux cibles en SSHv1 car c'est "pasécure lol".
 
Mais ils demandent de virer l'UAC sur les serveurs Windows pour que l'appli gère les mots de passe root  

Là pour une appli qui gère un système critique lié à de la sécu physique on a un partenaire qui trouve ahurissant qu'on utilise du https avec authentification pour qu'il charge des données dans l'appli par le net, "franchement je vais déjà vous donner mon IP pour que vous puissier la mettre dans votre firewall, faire plus ça sert à rien et de toutes façon mon appli sait pas faire autre chose que de l'http sans mot de passe ou quoi que ce soit". Et avec toujours, TOUJOURS, le même argument "on fait toujours comme ça et vous êtes le premier a qui ça pose problème"  

 
+1. si on m'avait filé dix balles à chaque fois qu'on me l'a sortie, je pourrais racheter facebook.

+1
Mais pourquoi vous vous embetez à faire ca, on a jamais eu ce genre de demande chez les autres clients  

 
Je me rajoute.
 
On est tjs les seule a le demander.

 
Sous Linux tu es maître de ta machine de A à Z. Tu tapes rm -rf / bien tampis pour ta gueule, la machine fait ce qu'on lui demande  

 
non mais les les mecs ils sont simplement con c'est pas possible. Je sais pas pour qu'elle boite du bosse, mais aux yeux de la loi, c'est licenciement pour faute grave directement

sur unix , je constate qu'il n'y a vraiement eu une prise de concience de la securite qu'avec le tremblement de terre qu'a ete la faille heartbleed de Openssl  
Avant on parlait tres peu de securité
depuis c'est un peu la paranoia , tout doit etre securisé avec signatures et certificats . au risque de prendre cher au niveau configurations et perfs.

c'est mes devs  
ils font des trucs comme ca deux fois par semaine et avec la bénédiction des chefs  
 
genre c'est normal qu'on trouve ~40 GO de fichiers temp et logs en tout genre sur un serveur  
et au bout de 2 ans a réclamer qu'ils corrigent ca, c'est un mec du support qui s'est pelé de pondre un utilitaire pour purger sans devoir le faire a la main  
 
 
un process vitale pour l'appli qui doit tourner en permanence  
-n'est pas déclaré comme service  
-ne se lance pas si la session est pas ouverte  
-plante si deux sessions sont ouverte ( deux instances => Fuck you )
-est tellement stable qu'il faut une tache planifié qui lance un BAT pour faire un kill/re init toutes les 20 minutes  
-arrive encore a se vautrer et provoque ~15 appels par semaine a la hotline ( sans compter les clients qui savent relancer sans nous )  
-était N°1 sur la liste prioritaire des bugs connu a corriger ( liste pondu par mon N+1 il y as 5 ans )  
 
ben non ... ca plante encore  
https://www.youtube.com/watch?v=p8oi6M4z_e0

 
 
 
 

Ouais j'en ai des comme ça aussi et je bosse avec tous les jours  
Faut vraiment que je change de boite

Petite question sur du Exchange (mutualisé OVH dans mon cas). Un utilisateur essaye de partager un dossier de contacts qu'il a créé spécialement en vue du partage. Donc je suis ce guide : https://www.ovh.com/fr/g1251.exchan [...] ct-outlook , et l'utilisateur destinataire du calendrier partagé le voit bien dans sa liste de contacts, mais pas dans ses carnets d'adresses. Il ne peut donc pas sélectionner d'adresse en provenance du dossier de contacts partagés car ils n’apparaissent pas. J'écume le web à la recherche de l'astuce qui me manque, mais je ne trouve rien, où est l'astuce pour faire apparaître un dossier de contacts partagés comme un carnet d'adresse ???    
 
(Office 2010, Exchange mutualisé 2013)

 
Beau roman    
 
Moi de mon coté mes (petits, on parle de TPE) clients ne sont pas prêts à assumer le cout financier pour que quelqu'un gère ça à leur place (ce qui sera cher, parce que pour se faire assurer en RC Pro ou en risque perte d'exploitation c'est pas donné), mais ne font pas le nécessaire eux même au quotidien. J'aime que le travail soit bien fait, mais plus trop donner de ma personne gratos pour des gens qui s'en foutent plus ou moins. Je continue donc de prendre sur moi et donner de mon temps et donc mon argent pour surveiller tout ça. Ou bien il faut que je me résigne à évoluer dans une nébuleuse de risque potentiel d'aller au clash avec le client le jour ou il y aura effectivement une perte. Mes CGVs précisant que l'exécution et le bon contrôle des sauvegardes reste de leur responsabilité...  
 
Je devrait traduire et leur envoyer ce lien, ça les sensibiliserait peut être un peu...
 
Dans les petites boites de toute façon rien au niveau des relations commerciales n'est clair et posé, ils essaient toujours d'en obtenir plus + tard, de tout renégocier n'importe quand, de ne s'engager sur rien à aucun moment (y compris à te payer dans des délais raisonnable ou tout court). Il m'arrive de recevoir des acomptes mais pas le devis et CGVs signées, des gens qui signent le devis puis essaient de renégocier, ou cassent la livraison... hmpf
 
 

C'est con mais c'est pas possible, faut à minima configurer la boite mail avec le dossier contact à partager en boite mail secondaire dans outlook.

Sérieux ? J'avais bien cru lire ça à demi-mot mais quand même !  

 
En même temps, Linux/Unix, ça a toujours été le trou noir de la sécurité dans les boîtes. Je n'ai jamais vu de clients avec ne serait-ce qu'un planning de patchs et de reboots formalisés. Auatnt il y a eu un déclic avec Windows, autant avec Unix/Linux, que dalle. Problème de culture/perception du danger différente ?

 
J'ai pas vu ça de mon côté. Par contre, les pratiques sont moins uniformes, parce qu'il existe autant de solutions que d'admins.
 
Les outils comme SaltStack/Ansible ont bien aidé à uniformiser ces dernières années.

Pourquoi faire un planning de reboot ? Avec du Ksplice/Kpatch ?

 
On dirait que la dernière version de OpenBSD empêche ce genre de gaffe :
https://linuxfr.org/news/openbsd-5-9

 
Déja, pour être sûr que ça puisse rebooter, en cas de problème  
 
Je parle sans vraiment troller, je l'ai déja eu vu, avec leur fetishisme de l'uptime, il y en a qui ne s'aperçoivent que le jour d'un grosse coupure électrique ou autre que leur système ne peut pas démarrer et mettent plusieurs heures à redémarrer le tout .
 
C'est comme le test de sauvegardes/restaurations, ça devrait être fait régulièrement.

A la limite, je préfère tester la restoration de la machine from scratch (template+applis+données, backup complet de la machine) et vérifier que tout marche bien, plutôt que de reboot régulièrement "pour le plaisir". Sinon, c'est la porte ouverte aux applis codées avec le fion qui bouffe de la ram comme des merdes parceque "de toutes façons, ça reboot tout les X jours, donc ce sera libéré". (J'ai même vu ça dans des préco fournisseur : "restart de service tous les jours, pour limiter les conséquences des fuites de mémoire qu'on a la flemme de patcher " ).
 
Mais au moins, le planning de reboot, si tu as du h24, ça t'oblige à avoir une HA qui marche bien, anéfé

J'ai vu plus souvent  des disques dont le moteur n'était plus capable de relancer la rotation que des applications nécessitant des reboot réguliers

Parce que ton serveur ne fonctionne pas tout seul   Tu coordonnes les arrêts avec les équipes de supervision, d'exploitation, de dev, voir le business.

J'ai vu des clients, souvent après de gros hacks, blinder leur infra Windows, ou du moins être habitués à patcher régulièrement les serveurs correspondants. Côté Linux/Unix, rien. Ensuite mon expérience est forcément limitée, mais ça s'est vérifié dans tous types de boîtes.