PDA

Bekijk Volledige Versie : chmod 777 daarna 644 vanaf root.. OEPS



soulshepard
21/02/09, 14:13
een collega van mij heeft op een plesk server / suse vanaf de root
een chmod 777 gedaan en daarna een 644

alle libs, bin sbins allemaal is de +x en andere rechten eraf.

zelf start de boel weerop, na wat 755 op de libs en bins, echter heel plesk qmail en msql wil gewoon niet meer

nu kan je via getfacl en setfacl rechten weer terug zetten
heeft iemand van mij een getfacl van qmail / mysql / plesk zodat ik dit kan vergelijken en mogelijk sneller aan de praat heb dan via een trial on error?

Thanks
soul

Herbert
21/02/09, 14:50
Als het een productie server is zet dan alles (met de nadruk op alles) even tijdelijk op 755 dan start die weer op.
Ga dan meteen de schrijfrechten goed zetten, niet te lang wachten!

Mikey
21/02/09, 14:53
psa: http://domains.mijn-sleutel.info/psagetfacl
qmail: http://domains.mijn-sleutel.info/qmailfacl
mysql: http://domains.mijn-sleutel.info/mysqlgetfacl

Welliswaar schone centos met 8.6 beter iets dan niets ;-)

soulshepard
21/02/09, 15:21
ok alvast bedankt

brb

soulshepard
21/02/09, 15:52
helaas 755 had ik ook al gedaan vanaf de root, maar echt de helft niet starten, zal bijna denken beter overnieuw installeren, mysql, qmail, en vanalles heb hier en daar kleine sicky bits bepaalde rechten etc.. hmm beetje bomen en bos gevoel

een herinstall van plesk is ook niet wat ik 123 een procedure van vind wellicht die autoinstaller. heb meer ervaring met directadmin.. anders had ik die herinstall allang gedaan

mikeh
21/02/09, 17:29
Heb je geen backup ??

systemdeveloper
21/02/09, 17:55
Een reinstall en een restore duurt 2 uur... hoe lang duurt het uitvogelen welk bestand welke rechten nodig heeft?

soulshepard
21/02/09, 18:20
ja restore, is de beste optie. maar eerst een goeie backup maken, want die was er volgens mij ook nooit. toch grappig overal waar je komt helpen is dat nooit echt lekker geregeld

:)

maar vanaf vandaag dan wel

bedankt alvast

laat het weten zodra het weer up is

:W:

soulshepard
23/02/09, 00:09
nou idd, backup, rebuild en restore toch het beste.
maar 2 uur met zelfs het snelste systeem is een beetje optimistisch :)
(behalve snapshots terug zetten natuurlijk)
uiteindelijk kost het toch een anderhalf dag.. aangezien je al meer als de helft kwijt bent met het backup maken, kopieren en terug halen nadat je een nieuw systeem hebt.

:)

thanks voor degene die snelle info gaven.

soul
:lovewht:

Mattie
23/02/09, 10:03
Helaas zelf (onlangs) zoiets gehad: 'chmod -R 777 /*' vanzelfsprekend moest die '/' er niet staan en helaas was root de enige die rechten had ik die map dus kon het niet anders. Ik draai Centos5 met DA en het meeste werkte nog. Is er niet een manier om die mysqlgetfacl-ding te gebruiken als 'input' ?

(DA heeft ook een repair scriptje in de scripts map zitten, maar daar heb je zeker niks aan)

Enliven.nl
23/02/09, 10:29
Eigenlijk zou je voor zulke commando's alsnog een vraag moeten krijgen, omdat je in de root bezig bent. Ondanks die -R

soulshepard
23/02/09, 10:45
Eigenlijk zou je voor zulke commando's alsnog een vraag moeten krijgen, omdat je in de root bezig bent. Ondanks die -R

precies helemaal mee eens -,-

en voor de script alike zaken dan een -absolutelysureyesoption

soulshepard
23/02/09, 10:52
Helaas zelf (onlangs) zoiets gehad: 'chmod -R 777 /*' vanzelfsprekend moest die '/' er niet staan en helaas was root de enige die rechten had ik die map dus kon het niet anders. Ik draai Centos5 met DA en het meeste werkte nog. Is er niet een manier om die mysqlgetfacl-ding te gebruiken als 'input' ?

(DA heeft ook een repair scriptje in de scripts map zitten, maar daar heb je zeker niks aan)

de getfacl zijn tegenhanger is setfacl --restore=/file dit werkt wel, alleen hielp in dit geval niet. al met al moest mysql onder root draaien om het aan de praat te krijgen, voor mij niet echt een optie, wat mij besloot om de boel overnieuw te installeren was dat qmail op deze server gewoon niet wou meewerken na een aantal uur. vandaar. maar ook al had ik de boel 100% aan de praat gekregen, had ik wel later overnieuw geinstalleerd, alles op 777 niet echt handig. wat ik wel weet is dat ik een getfacl in een cron laat meelopen get &setfacl was nieuw voor mij tot dit weekend. altijd wel handig een dergelijke file system rechten backup

soulshepard
23/02/09, 12:18
ps: een andere vriend van mij kwam ook met hetvolgende: (thx fash)

for p in $(rpm -qa); do rpm --setperms $p; done
for p in $(rpm -qa); do rpm --setugids $p; done

dit zou ook zeer effectief zijn geweest, (weet niet als alle rpm's er ook voor aanwezig moest zijn, maar ga ik het zeker even nakijken. zou in dit geval veel tijd hebben bespaard.)
maar voor degene die het devolgede keer tegenkomt... doe je voordeel ermee
:D

MediaServe
23/02/09, 13:58
Bij dergelijke fouten in reeks lijkt mij een reinstall de enige wijzelijke oplossing. Je wilt op een productieserver geen risico lopen dat er toch nog fouten in de beveiling zitten. De genoemde oplossingen zijn leuk voor tijdelijk, maar zorg er dan voor dat je dezelfde dag het besturingssysteem opnieuw gaat installeren.

systemdeveloper
23/02/09, 14:17
ps: een andere vriend van mij kwam ook met hetvolgende: (thx fash)

for p in $(rpm -qa); do rpm --setperms $p; done
for p in $(rpm -qa); do rpm --setugids $p; done

dit zou ook zeer effectief zijn geweest, (weet niet als alle rpm's er ook voor aanwezig moest zijn, maar ga ik het zeker even nakijken. zou in dit geval veel tijd hebben bespaard.)
maar voor degene die het devolgede keer tegenkomt... doe je voordeel ermee
:D
Leuk, je wil niet weten wat je dan allemaal mist, maar een reinstall blijft sneller en veiliger.

Voorbeeld: in bestanden zoals newsyslog.conf kun je bv. vaak *.* laten loggen naar een aparte file om alle info in 1 bestand te verzamelen. Handig voor log analyses, maar dat is niet een bestand dat je in die rpm gaat terugvinden en op 644 wil je dit ook niet hebben.

Ook leuk om te weten. Als je maat vanaf de root een chmod 644 doet, dan werkt dat ook op je /dev/*.
Daarmee had je dus elke bit met informatie van je schijf voor elke non-priviliged user leesbaar gemaakt.

Geinig om te weten in geval je vertrouwt op alleen die rpm regeltjes, dacht ik...

mikeh
23/02/09, 16:53
precies helemaal mee eens -,-

en voor de script alike zaken dan een -absolutelysureyesoption

Waar denk je waar "sudo" voor dient ?? :rolleyes:

soulshepard
23/02/09, 16:54
okeokeoke :D :lovewht:

even voor de goede orde, heb inderdaad de server opnieuw geinstalleerd. en zou het ook zeker niet door laten lopen en vertrouwen met een server waarvan alle rechten overal vaag staan. die rpm regeltjes ent setfacl zag ik ook niet als een fix maar meer in de trend van een snelle manier om alles weer enigsinds aan te praat te maken, zonder dat je een paar uur bezig bent met trial on error het toch "even" aan de praat te maken, al met al was het wel nodig om dat te doen, om er uberhaubt een backup van te kunnen maken, maar een herinstall was en is de enige nette manier :)

nogmaals thx iedereen voor de input ;)

Soul

ps: en nee ik was niet degene met de chmod hihi :)

Mikey
23/02/09, 22:55
Ook leuk om te weten. Als je maat vanaf de root een chmod 644 doet, dan werkt dat ook op je /dev/*.
Daarmee had je dus elke bit met informatie van je schijf voor elke non-priviliged user leesbaar gemaakt.

Geinig om te weten in geval je vertrouwt op alleen die rpm regeltjes, dacht ik...

Geinig dat je dev ook gewoon uit de rpmtjes uitgerold wordt...

systemdeveloper
23/02/09, 23:36
Geinig dat je dev ook gewoon uit de rpmtjes uitgerold wordt...
Ok, vertrouw er maar op.

Mattie
24/02/09, 09:08
okeokeoke :D :lovewht:

....

ps: en nee ik was niet degene met de chmod hihi :)

Nee dat was ik en helaas was die '/' een typfout :(
(en nog een keer helaas was root de enige die rechten had daarzo)
Maar gelukkig is het toch een hobby-bak ;p

Die getfacl laten draaien in de cron vind ik wel een goeie :) ff linux op een ouwe pc mikken getfacl doen rechten verkl*** en kijken of ik het zo terug kan krijgen :)

(owja een bevestiging vind ik ook wel wat ;p)

systemdeveloper
24/02/09, 10:05
Ach, ik heb vroeger eens een rm -rf .* gedaan om alle dotfiles even snel te verwijderen voordat ik ging lunchen... helaas hoorde daar ook '..' bij en na 5 minuten belden de mensen waar hun home-directory was gebleven... toen kwam de lunch spontaan terug :)

Spyder01
24/02/09, 12:19
Dit soort fouten zijn natuurlijk fouten die je nniet op een productieplatform moet maken. Maar we zijn en blijven mensen en kunnen dus fouten maken. Een tikfout is ook zo gemaakt, zeker als je nog snel even iets wilt regelen.

Alleen jammer van alle nasleep e.d. die je dan hebt. Volgens mij let je dan de volgende keer nog beter op!