[FreeBSD] voorkomen dat symbolic link verwijderd wordt *

[Keiichi]

Ik draai een server met 4.11-stable.
Om gebruikers tegen hun eigen stomiteiten te beschermen mogen ze bepaalde bestanden van hun eigen niet verwijderen. chflags schg,sunlnk *bestand* werkt goed
Maar ik heb tevens enkele symbolic links. Die weet ik op geen manier te beschermen. chflags kunnen niet op de link worden gezet. Dit lijkt pas vanaf 6.0 erin gekomen te zijn, maar op dit moment update en doen ben ik niet van plan. (Ooit heb ik al praktisch een live upgrade tussen major versies uitgevoerd en was niet voor herhaling vat baar (wel goed gelukt trouwens))
Een chmod + chown op de symbolic link (Wel met chmod -h en chown -h) lijkt FreeBSD niets van aan te trekken en laat de gebruiker de symbolic links gewoon verwijderen

iemand nog suggesties?

[Z-Dragon]

Misschien dat ik niet weet waar ik over praat, met FreeBSD 4.11, maar is de sticky bit daar niet voor? Gebruiker volledige rechten geven maar geen eigenaar maken. Dan de sticky bit zetten?

[Verwijderd]

Keiichi schreef op woensdag 10 mei 2006 @ 21:48:
Dit lijkt pas vanaf 6.0 erin gekomen te zijn, maar op dit moment update en doen ben ik niet van plan. (Ooit heb ik al praktisch een live upgrade tussen major versies uitgevoerd en was niet voor herhaling vat baar (wel goed gelukt trouwens))

Lichtelijk off topic maar ik kan uit eigen ervaring vertellen dat een source upgrade van 4.11 naar 5.4 al niet aan te bevelen is (mijn poging resulteerde in een compleet overleden systeem), van 4.11 naar 6.0 is het (zo goed als) onmogelijk.

[Verwijderd]

Als je de symbolic links als root maakt(chown root?) lijkt het mij sterk dat de gebruikers die kunnen verwijderen.

[Z-Dragon]

De mensen achter FreeBSD raden aan pas vanaf versie 5.3 naar 6.1 te upgraden. Daaronder eerst naar 5.3. Hoe goed of minder goed dat verloopt weet ik verder niet.

[xzenor]

Mijn mening is dat je het beste compleet kan herinstalleren als je van 4 naar 5 of 6 wilt...
Er blijft zoveel ouwe rotzooi achter van het vorige OS. Dat vertrouw ik gewoon niet..

ik weet ook wel dat dit in een bedrijf (en vaak zelfs thuis) niet echt een van de meest populaire opties is Maar het is wel de meest veilige manier als je een stabiel systeem wilt.

Als bedrijf wil je ook nog geen 6.x gaan draaien. Die is nog niet stable dus dat is een behoorlijk groot risico als je dat als bedrijf gaat gebruiken in een productie-omgeving.

[blaataaps]

possamai schreef op donderdag 11 mei 2006 @ 17:44:
Mijn mening is dat je het beste compleet kan herinstalleren als je van 4 naar 5 of 6 wilt...
Er blijft zoveel ouwe rotzooi achter van het vorige OS. Dat vertrouw ik gewoon niet..

Waarom vertrouw je dat niet? Die "oude rotzooi" (die overigens als het goed is wel meevalt) doet niet zo heel veel lijkt me.

ik weet ook wel dat dit in een bedrijf (en vaak zelfs thuis) niet echt een van de meest populaire opties is Maar het is wel de meest veilige manier als je een stabiel systeem wilt.

Waarom is het veilig? Waarom is het stabiel? De upgradeprocedures zijn behoorlijk goed, en als je UPDATING leest kan er meestal weinig misgaan (en reinstall kan altijd nog)

Als bedrijf wil je ook nog geen 6.x gaan draaien. Die is nog niet stable dus dat is een behoorlijk groot risico als je dat als bedrijf gaat gebruiken in een productie-omgeving.

Onzin, sterker nog, de 2e production release van 6.x is inmiddels een paar dagen uit (6.1 dus).
Je mag best dingen beweren als "x is niet stabiel" of "dit moet je niet doen", maar onderbouw het dan iets meer dan je nu doet en noem wat meer feiten in plaats van alleen maar FUD

[Keiichi]

Verwijderd schreef op donderdag 11 mei 2006 @ 01:29:
Als je de symbolic links als root maakt(chown root?) lijkt het mij sterk dat de gebruikers die kunnen verwijderen.

Maar het kan gewoon schijnbaar sticky bit helpt ook niets.

[blaataaps]

Verwijderd schreef op donderdag 11 mei 2006 @ 01:29:
Als je de symbolic links als root maakt(chown root?) lijkt het mij sterk dat de gebruikers die kunnen verwijderen.

Het verwijderen van een file hangt af van de rechten op de directory waar het bestand staat, niet van de owner van het bestand, dat kan dus prima onder bepaalde omstandigheden (in iemands homedir bijvoorbeeld, waar men in het algemeen schrijfrechten heeft enzo).

[ Voor 4% gewijzigd door blaataaps op 12-05-2006 00:27 ]

[xzenor]

blaataaps schreef op donderdag 11 mei 2006 @ 17:53:
[...]
Waarom vertrouw je dat niet? Die "oude rotzooi" (die overigens als het goed is wel meevalt) doet niet zo heel veel lijkt me.

Over het algemeen zijn er nogal wat behoorlijk grote verschillen tussen verschillende branches. Ik heb het ooit van 3 naar 4 geprobeerd maar dat was een hele missie en het draaide toch niet helemaal lekker..

blaataaps schreef op donderdag 11 mei 2006 @ 17:53:
[...]Waarom is het veilig? Waarom is het stabiel? De upgradeprocedures zijn behoorlijk goed, en als je UPDATING leest kan er meestal weinig misgaan (en reinstall kan altijd nog)

Reinstall kan inderdaad altijd nog..
Daar heb je gelijk in. Ikzelf vertrouw het alleen nooit zo. Puur een eigen mening, maar als ik dan een fout tevoorschijn zie komen ga ik toch twijfelen of dat aan de upgrade ligt of niet.
De upgrade procedure van bijvoorbeeld 5.4 naar 5.5 is perfect, helemaal niets over te zeiken. Alleen van 5.x naar 6.x durf 'ik' niet zomaar aan.

[...]blaataaps schreef op donderdag 11 mei 2006 @ 17:53:Onzin, sterker nog, de 2e production release van 6.x is inmiddels een paar dagen uit (6.1 dus).

Ehm nou ik heb het woord "stabiel" nooit gebruikt.. Ik had het over de branche-naam -STABLE
misschien had ik het in hoofdletters moeten doen zoals het officieel ook is.
Maar ik begreep uit een andere post dat 6.1 zelfs al -STABLE is.

Ik had het gewoon niet verwacht aangezien bij 5.x het pas STABLE ging heten vanaf 5.3.
DUs 5.0, 5.1 en 5.2 zijn nooit -STABLE geweest.
Ik had verwacht dat het bij 6 ook wel zo zou gaan eigenlijk.

blaataaps schreef op donderdag 11 mei 2006 @ 17:53:
Je mag best dingen beweren als "x is niet stabiel" of "dit moet je niet doen", maar onderbouw het dan iets meer dan je nu doet en noem wat meer feiten in plaats van alleen maar FUD

Zo beter?
Ik zat fout (blijkbaar) of dat het nog niet -STABLE was, maar mijn mening over upgraden is nog niet veranderd. Naar mijn idee is een clean install nog steeds beter dan een upgrade, maar dat ligt vooral aan mijn eerdere ervaringen van 3.x naar 4.x.
Als het nu makkelijker en beter schijnt te gaan zal ik het binnenkort wel eens proberen, want ik draai nog steeds 5.x..

[Michael]

De upgrade van 5.x naar 6.x komt eigenlijk bijna op hetzelfde neer als van bijvoorbeeld 5.2 -> 5.3. De overstap van 4.x naar 5.x is inderdaad wat meer werk, maar dat was dan ook een resultaat van 2 a 3 jaar ontwikkeling oid.

[Keiichi]

ik heb het niet naar m'n zinnen voor elkaar gekregen.
het enige wat geholpen heeft is de write permission van de directory ontnemen. Maar dat is niet geheel de bedoeling omdat de gebruiker ook in de directory nog moet schrijven.

offtopic:
Ik zal misschien nog even vertellen hoe ik zelf een update eens heb uitgevoerd. Het was een upgrade tussen 4 releases, maar ik had besloten om het niet op de FreeBSD update manier te doen omdat ik met een soort van schone lei wou beginnen. Door veel te testen op verkeerde plekken was het een en ander vervuild. (Bv, verschillende openssl versies in /usr en /usr/local )

De server was verdeeld in een data partitie en OS partitie. Van tevoren heb ik goed gekeken welke configs ik van de OS partitie nog nodig had. Oftewel: Backup maken van alles wat 'etc' als directory is.
Omdat ik geen backup middelen had om desnoods de datapartitie veilig te stellen was dit ook niet gebeurd
De OS partitie heb ik in z'n geheel leeg gehaald en de laatste release opgezet. Alle ports die ik nodig had heb ik weer opnieuw gecompiled. Er was tevens een hoop custom gecompiled aanwezig. In de weken voorgaand van de update-plannen heb ik op een test systeem script zitten te bouwen om alles opnieuw te bouwen.

Alles is godzijdank zonder complicaties verlopen en ik had na ongeveer 3 a 4 uur de server back up and running.

Of ik dit weer zo zou doen? Nee, never nooit niet Ik heb toen hele peeen gezweet door angst iets kwijt te raken of niet binnen 'normale' tijd back up te zijn.