[BC3] geen rechten meer als admin?

[MinddiggerNL]

Hoi,

Ik heb een probleempje met mijn e-smith linux gateway. Ik heb hem laatst geinstalleerd en toen deed alles het goed. Nu heb ik van de week een rpm geinstalleerd voor statistieken van mijn website (AWstats) en phpsysinfo geinstalleerd. Echter....nu heb ik opeens problemen met het schrijven, renamen en verwijderen van bestanden in de directory waar mijn website in staat Ik weet niet of het aan de installatie van deze twee pakketten ligt maar het is wel zeer vervelend. Ik ben als admin ingelogd en dan zou ik normaal gesproken de rechten moeten hebben om dit te doen via bijv. de windows verkenner.
Ik heb zojuist de dir leeg gemaakt maar ik kan er nu dus niks meer in zetten. Hoe kan ik dit het beste oplossen? Ik dacht er zelf aan om die lege dir eerst te verwijderen met rmdir en vervolgens hem weer opnieuw aan te maken. Maar kan dat zomaar? Of moet ik dan weer een heleboel gaan instellen?

Iemand ervaring hiermee? Ik weet niet of het hier anders gaat dan normaal omdat het e-smith betreft...een aangepaste redhat distro.

[MinddiggerNL]

niemand een idee? Is er niemand die wat meer ervaring heeft met e-smith? Ik heb deze dingen ook al gevraagd op het forum van e-smith maar daar krijg je haast nooit een antwoord
Ik kan ook opeens niet meer printen

[Verwijderd]

Op vrijdag 04 mei 2001 12:26 schreef timotheebastin het volgende:

Echter....nu heb ik opeens problemen met het schrijven, renamen en verwijderen van bestanden in de directory waar mijn website in staat

mischien heeft hij de bestanden ge-installeerd met root als eingenaar.

je kunt wat proberen met chown en chgrp

[MinddiggerNL]

bedankt! ik heb met chown opgegeven dat de user admin behoort bij /home/e-smith/files/primary/html en nu kan ik er weer files heen kopieren.

Maar hoe kan ik voordat ik zo''n weiziging doorvoer/intik een overzichtje krijgen van hoe de rechten reeds ingesteld zijn? Dus hoe had ik kunnen zien welke user er rechten had in de bovengenoemde dir voordat ik het ging aanpassen naar admin?

[balk]

met ''ls -alF'' zie je alle rechten.

[MinddiggerNL]

ik kan nu dus wel leuk files kopieren en hernoemen in die directory dus dat probleem is opgelost maar blijkbaar was het ook niet de methode om dan maar te zeggen dat die dir bij user admin hoort want nu kan mijn site niet meer bekeken worden. Krijg je steeds een 403 error of een php error. Die php error komt waarschijnlijk door het feit dat ik phpsysinfo heb geinstalleerd. Wie kan me ff vertellen hoe ik dit weer weg krijg? Ik kan die files wel weggooien maar dan moet ik nog die php.ini aanpassen en daar heb ik bij path ".". ingevuld en weet ik niet meer wat er eerst stond

Hoe kan ik er nu voor zorgen dat mijn site weer zichtbaar wordt? Ik heb het idee dat nu alleen maar de admin in die dir kan komen....terwijl iedereen er van moet kunnen lezen om de site op internet te kunnen zien.
Met dat ls -alF krijg ik inderdaad een mooi overzichtje maar daar zie ik slechts van de hoofddir''s te zien dat ze bij root horen. Kan dat niet wat specifieker?

[Verwijderd]

kijk je moet even uit zoeken hoe het rechten systeem werkt van linux. vervolgens moet je dus de dir''s goed zetten. als je een bestand of een dir maakt en die alleen lees baar maakt als root heb je het probleem als nu. je moet dus ook nog eens met chmod aan de gang

chmod 750 /var/www/html (ofzo)

oja...dat 750...bijt me er niet op vast!

man chmod! (zonder die ! uiteraard )

[BC3 Victim]

Op zaterdag 05 mei 2001 17:29 schreef balk het volgende:

met ''ls -alF'' zie je alle rechten.

Ohja?! ... ik zou het proberen met ls -o

[Verwijderd]

Op zondag 06 mei 2001 15:59 schreef A_Dude het volgende:

[..]

Ohja?! ... ik zou het proberen met ls -o

met ls -al(F) zie je dus alle bestanden (inclusief hidden bestanden).
met ls -o zie je dus niet alle bestanden en ook niet de groep waartoe een bestand hoort.

De eerste is voor admin IMHO dus een handiger commando, maar dat kan aan mij liggen:?

[MinddiggerNL]

bedankt voor de tips...ik ga eens met chmod aan de gang Het lijkt er nu inderdaad op dat alleen de admin user (die overigens bij e-smith volgens mij gelijke rechten heeft als root) rechten heeft in die map, terwijl eigenlijk iedereen moet kunnen lezen.

[Verwijderd]

dan doe maar eens "chmod 644" voor je internet-bestandjes.

[MinddiggerNL]

Op zondag 06 mei 2001 18:52 schreef nelske het volgende:
dan doe maar eens "chmod 644" voor je internet-bestandjes.

Ik heb eens ff opgezocht in mijn linux boek hoe het zit met dat chmod maar is het niet beter om ipv chmod 644 chmod 557 te doen voor die bestanden of de directory? Als ik het goed begrijp zou het dan nl. zo ingesteld zijn:
xr voor others
xr voor group
xwr voor user (admin/root in dit geval)

Of evt. 577?

Of sla ik nu helemaal de plank mis?

[Verwijderd]

Ik weet niet wat voor een boek dat is hoor, maar dat boek slaat de plank enorm mis!!!!
Hetgeen jij opgaf zou betekenen, dat iedereen behalve de eigenaar van het bestand en de groep waartoe het hoort volledige toegang krijgt (read (=4), write(=2), execute(=1))

De volgorde is dus: user, group, other
Verder is 7 niet nodig; dan zet je namelijk de execute vlag ook nog eens aan, dat is nergens voor nodig.
Zoals ik het op gaf (644), heeft de eigenaar van het bestand read/write rechten en de group waartoe het bestand hoort, evenals de rest van de wereld heeft alleen lees-rechten.

[MinddiggerNL]

oké...nou dat zal niet aan Leerboek Linux wat ik dus heb liggen maar aan mij
Ik las dat je bij de notatie van dat getal (644 of 577 in mijn geval) de 1,2 en 4 kon optellen en daardoor dus op 7 kon uitkomen. Daaruit formuleerde ik dus mijn idee. Ik was van mening dat ik met 577 de user en de group alle rechten gaf (1+2+4=7) en de rest van de wereld lees en execute rechten gaf (execute voor bijv. php ofzo dacht ik).

Vandaar dat ik op dat getal uit kwam.
Ik zag net echter dat zoals het nu is ingesteld de user admin lees en schrijf rechten heeft, de groep alleen leesrechten en others niks
Dus ik moet ff die others leesrechten geven en dan zou het goed moeten zijn.

[MinddiggerNL]

I know Ga het dadelijk proberen. Thanx anyway!

[Verwijderd]

Yep dan is het helemaal goed.
Tja wat het commando daarvoor is?
Ik heb het inmiddels 2 maal gegeven;)

Oh ja voor php bestandjes die via je webserver geparsed worden heb je geen execute-permisssies nodig.
Execute is alleen nodig voor scripts en programma''s.

Tip: Kijk ook eens naar de optie -R bij chown om recursief bestands-permissies te veranderen.

[MinddiggerNL]

nou ja...kom ik weer

Het werkt niet!

Ik heb het chmod commando in relatieve modus gebruikt dus ik heb dit ingetikt:
chmod u=rwx,g=r,o=r /home/e-smith/files/primary/html/*

Nu heeft elke file dus dit ervoor staan:
-rwxr--r-- een getal(geen idee wat het aangeeft) admin shared (als group...wist ik niet maar moest volgens de rest van de ibays)

Ook als ik de group admin maak of de rechten anders verdeel doet mijn website het niet!

Ik snap er nu echt niks meer van. De rechten zouden nu goed moeten zijn ingesteld en ik heb de webserver al eens geherstart maar de site blijft forbidden

Iemand een idee wat ik fout gedaan zou kunnen hebben?

[Verwijderd]

De rechten zijn nu wel goed (hoewel die execute nergens op slaat voor de user, maar goed).

Staat de documentroot wel goed?

[MinddiggerNL]

Op zondag 06 mei 2001 22:14 schreef nelske het volgende:
De rechten zijn nu wel goed (hoewel die execute nergens op slaat voor de user, maar goed).

volgens mij stond dat overal zo maar dat boeit niet zo lijkt me.

Staat de documentroot wel goed?

geen idee, hoe check ik dat?

[MinddiggerNL]

nou ik heb dus eens gekeken in de file httpd.conf om te kijken wat de documentroot is maar die staat vreemd genoeg ingesteld op /etc/e-smith/web/panels/manager/html

geen idee of dat zo hoort maar dat zal dan wel. Ik heb ook het idee dat dit iets anders is dan bij de gewone redhat waar e-smith op is gebaseerd maar ik heb verder geen flauw idee waar het nu aan kan liggen.

Ik weet wel een oplossing en dat is om e-smith gewoon te herinstalleren maar dat wil ik dus niet want dan moet ik weer eerst de hele zooi zoals alle mailaccounts gaan backuppen.

[Verwijderd]

Op zondag 06 mei 2001 23:34 schreef timotheebastin het volgende:
volgens mij stond dat overal zo maar dat boeit niet zo lijkt me.

Tja een van de redenen waarom servers vaak enorm makkelijk te hacken is het niet op letten van de beheerders van die server op de bestandspemissies. Je moet me toch een ding uitleggen: waarom zou je een bestand meer permissies geven dan strict noodzakelijk.
Okee een html-bestandje of gifje kan je welliswaar niet uitvoeren, maar door zo laks met permissies om te gaan, maak je een soortgelijke fout gegarandeerd een keer met een script of programma waarbij het dus wel kwaad kan.

nou ik heb dus eens gekeken in de file httpd.conf om te kijken wat de documentroot is maar die staat vreemd genoeg ingesteld op /etc/e-smith/web/panels/manager/html

Zullen we daar dan maar niet even de directory vanwaar jij je bestanden wil serven invullen:?
Tja het lijkt misschien stom hoor, maar daarvoor is DocumentRoot.

Verder kijk ik altijd op de website van de fabrikant zelf als ik een probleem met bepaalde software heb. Tja hoe ik erbij kom:?

geen idee of dat zo hoort maar dat zal dan wel. Ik heb ook het idee dat dit iets anders is dan bij de gewone redhat waar e-smith op is gebaseerd maar ik heb verder geen flauw idee waar het nu aan kan liggen.

httpd.conf is gewoon het configuratie bestand van Apache. Het is de bedoeling dat je zo''n bestand eventueel zelf naar eigen smaak indeeld en vervolgens apache opnieuw opstart. Verder is het gewoon Apache en dat heeft niks met de distributie te maken.

Ik weet wel een oplossing en dat is om e-smith gewoon te herinstalleren maar dat wil ik dus niet want dan moet ik weer eerst de hele zooi zoals alle mailaccounts gaan backuppen.

AAAAaaaaaargggggghhhhhhh, dat meen je toch niet he?
Als mijn auto een beetje trilt in het stuur, verkoop ik hem toch ook niet meteen!

Verder is het geen windows>:), dat je om de zoveel tijd weer een keer opnieuw moet installeren. Het is dus de bedoeling dat als een bepaald programma niet werkt, dat je dan eens binnen dat programma kijkt waar het probleem ligt. Als je het probleem dan eventueel niet kunt lokaliseren, dan kun je eens gaan kijken of je het programma zelf niet eens kunt updaten of herinstalleren.

[MinddiggerNL]

Op maandag 07 mei 2001 01:19 schreef nelske het volgende:

[..]

Tja een van de redenen waarom servers vaak enorm makkelijk te hacken is het niet op letten van de beheerders van die server op de bestandspemissies. Je moet me toch een ding uitleggen: waarom zou je een bestand meer permissies geven dan strict noodzakelijk.
Okee een html-bestandje of gifje kan je welliswaar niet uitvoeren, maar door zo laks met permissies om te gaan, maak je een soortgelijke fout gegarandeerd een keer met een script of programma waarbij het dus wel kwaad kan.
[..]

Ja daar heb je wel gelijk in. Ik zal die execute rechten er ook afhalen, maar dat vond ik niet echt prioriteit.

Zullen we daar dan maar niet even de directory vanwaar jij je bestanden wil serven invullen:?
Tja het lijkt misschien stom hoor, maar daarvoor is DocumentRoot.

Dat ga ik dus ook proberen Ik heb gelukkig laatst bij nog iemand e-smith geinstalleerd en dus ga ik die bestanden maar eens ff met die van hem vergelijken.

Verder kijk ik altijd op de website van de fabrikant zelf als ik een probleem met bepaalde software heb. Tja hoe ik erbij kom:?
[..]

Ja geen idee hoe je op dat idee komt
Nee tuurlijk heb ik dat al gedaan! Ik heb alles nagezocht maar omdat die twee pakketjes die ik had geinstalleerd niet officieel bij e-smith horen is er ook geen support voor en op het forum van e-smith.org duurt het ook ontzettend lang voordat je een antwoord krijgt, als je het al krijgt! Vandaar dat ik hier hulp zocht.

httpd.conf is gewoon het configuratie bestand van Apache. Het is de bedoeling dat je zo''n bestand eventueel zelf naar eigen smaak indeeld en vervolgens apache opnieuw opstart. Verder is het gewoon Apache en dat heeft niks met de distributie te maken.
[..]

Aha...ja ok dat vat ik wel, maar e-smith heeft een of andere methode met templates waar je veranderingen in mag maken. zo mag je dus niet de originele bestanden weizigen maar alleen die templates. althans dat wordt aanbevolen. die template bestanden overrulen dan weer de originelen. Vandaar dat ik er niet zo snel in ging klooien.

AAAAaaaaaargggggghhhhhhh, dat meen je toch niet he?
Als mijn auto een beetje trilt in het stuur, verkoop ik hem toch ook niet meteen!

Verder is het geen windows>:), dat je om de zoveel tijd weer een keer opnieuw moet installeren. Het is dus de bedoeling dat als een bepaald programma niet werkt, dat je dan eens binnen dat programma kijkt waar het probleem ligt. Als je het probleem dan eventueel niet kunt lokaliseren, dan kun je eens gaan kijken of je het programma zelf niet eens kunt updaten of herinstalleren.

Nee heb je gelijk in. Ik was ook van mening dat dat met linux zeker niet nodig zou zijn daarom heb ik ook eerst dit geprobeerd. Maar als het zelfs met het aanpassen van de documentroot dadelijk niet is verholpen zie ik mij daar toch toe genoodzaakt.
Het klinkt misschien stom, dat is het ook wel een beetje geef ik toe, maar als redelijke linux newbie is dat in zo''n geval toch wel de makkelijkste manier. Ik wil nl. dat die server het fatsoenlijk doet en herinstalleren gaat dan sneller dan waar ik nu mee bezig ben. Klooien met linux en het uitvogelen van dit soort dingen doe ik liever op mijn testpc dan op mijn server.

Maar goed, ik ga die bestanden maar eens ff vergelijken met die van die ander en dan die httpd.conf eens aanpassen. Hopelijk is het daarmee opgelost.

[MinddiggerNL]

Sjezus man...ik begrijp er werkelijk niks meer van

Ik heb de httpd.conf files vergeleken (dat waren er 4 op verschillende locaties) en alles stond toch zoals het hoorde.

Daarna heb ik alle rechten aangepast zoals het oorspronkelijk was (dat heb ik dus ook bij die andere e-smith bak vergeleken) voor de files en voor de directory''s.

Toen heb ik de webserver ff geherstart en nog doet mijn site het niet
Krijg nog altijd te zien error 403 - U bent niet gemachtigd om deze pagina te bekijken.

Op zich leer je hier natuurlijk wel veel van want ik kan nu met de commando''s chmod, chown en chgrp goed overweg maar je kunt je toch wel voorstellen dat het voor een beginner wat leuker is als het daarna ook werkt.

Iemand nog een idee wat het kan zijn? Of is er meer info nodig?

[Verwijderd]

hehe, wat voor rechten heeft de dir waar je website in staat? en van alle bovenliggende
moet ook world-exacutable zijn enzo. je server moet er wel in kunnen komen hè:)

[MinddiggerNL]

Op maandag 07 mei 2001 16:02 schreef C[e]rial het volgende:
hehe, wat voor rechten heeft de dir waar je website in staat?

Nou die html directory waar de bestanden instaan heeft de volgende rechten:

drwxr-s--- 3 admin shared 4096 May 7 15:48 html

dat lijkt me toch genoeg Bovendien heb ik deze instellingen bij een andere, wel nog werkende, e-smith server afgekeken! Kun je me misschien meteen verklaren waar die 3 voor staat vóór admin?

en van alle bovenliggende
moet ook world-exacutable zijn enzo. je server moet er wel in kunnen komen hè:)

Hoe bedoel je dat?

Daarnaast viel het me in dat het wel eens zo zou kunnen zijn dat er wat mis is met de rechten van de group shared. Met welk commando kan ik achterhalen wie er in de group shared zit en welke rechten er aan die group zijn verbonden???

[MinddiggerNL]

Niemand meer een ingeving? Kan het niet wellicht aan de firewall liggen? Dus aan de ipchain rules?

[Verwijderd]

Heb je die defaultroot al aangepast?
Heb je verder wel een bestandje index.htm of index.html in die defaultroot staan?

Ik gok het niet namelijk en apache zal wel zo ingesteld staan, dat directorylistings niet toegestaan worden.
Kijk ook eens naar de config-optie DirecttoryIndex.

Verder moet die directory, vanwaar je de bestanden serveert zelf dus wel de volgende rechten hebben: 755

[MinddiggerNL]

Op maandag 07 mei 2001 21:27 schreef nelske het volgende:
Heb je die defaultroot al aangepast?

Die bleek toch goed te staan Heb ik schijnbaar naar iets anders gekeken gister maar er stonden vier httpd.conf files op de server en alle vier waren ze hetzelfde ingesteld als die files op die server van die ander waar ik hem heb geinstalleerd en die het wel doet. Dus dat zou goed moeten zijn. Er staat daar als documentroot:
/home/e-smith/files/primary/html

Heb je verder wel een bestandje index.htm of index.html in die defaultroot staan?

Jawel....er staat het bestand index.htm in de dir /home/e-smith/files/primary/html dus dat is ook goed!

Ik gok het niet namelijk en apache zal wel zo ingesteld staan, dat directorylistings niet toegestaan worden.
Kijk ook eens naar de config-optie DirecttoryIndex.

DirectoryIndex? Staat die ook in die httpd.conf file? Dan moet ik daar eens naar kijken.

Verder moet die directory, vanwaar je de bestanden serveert zelf dus wel de volgende rechten hebben: 755

Dat stond dus anders ingestel, ook op die wel werkende server, maar dat heb ik nu veranderd naar de waarde die je op gaf.
de dir /home/e-smith/files/primary/html heeft nu deze rechten: drwxr-xr-x en het was drwxr-x---


Ik heb vervolgens weer eens ff httpd opnieuw opgestart maar nog steeds krijg ik error 403 forbidden

[Verwijderd]

En als je achter de URL direct index.htm plakt, doet hij het dan wel?
Dit moet toch echt wel aan de bestandspermissies liggen, als de rest wel goed staat!

[MinddiggerNL]

Op maandag 07 mei 2001 21:42 schreef nelske het volgende:
En als je achter de URL direct index.htm plakt, doet hij het dan wel?
Dit moet toch echt wel aan de bestandspermissies liggen, als de rest wel goed staat!

Nee zelfs als ik www.minddigger.com/index.htm intik doet ie niks

Ja ik heb geen idee meer waar het aan kan liggen. Kan het niet aan ipchains liggen ofzo? Of zou ie het dan in ieder geval wel nog intern moeten doen?

[BC3 Victim]

Welke user gebruikt apache? Doe een chown op de html dir naar die user... Idem voor alle bestanden..


Voeg daarna de root toe aan de groep van apache users en ''t zou moeten werken..

[Verwijderd]

Ipchains kan het niet zijn, anders zou je geen 403 krijgen (Connection Refused) van de webserver!

Zet anders eens het volgende erin en controleer of er niks conflicterends met deze regels in je httpd.conf staat.

code:

<Directory "/home/e-smith/files/primary/html">
    Options Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Heb je verder niet toevallig een Virtualhost in je config staan met een andere defaultroot?
Of een bestandje .htaccess waarin toegang wordt geblokeerd!

Probeer anders eens te telnetten op poort 80 naar je webserver en kijk of de verbinding niet geweigerd wordt.

Kijk ook eens in de apache log-files wat daar staat!!

[MinddiggerNL]

Op maandag 07 mei 2001 21:50 schreef hezik het volgende:
Welke user gebruikt apache? Doe een chown op de html dir naar die user... Idem voor alle bestanden..


Voeg daarna de root toe aan de groep van apache users en ''t zou moeten werken..

Als ik in de file httpd.conf kijk staat er vrij bovenaan iets van user www en group www. Ik heb op de dir en de files van mijn site aangegeven dat user admin en group shared ze beheren/bezitten. Dat lijkt tegenstrijdig maar dat is op die wel goed werkende e-smith bak ook zo dus dat veronderstel ik als correct geconfigureerd.

Maar hoe kan ik zien welke rechten de group shared heeft en welke users daartoe behoren? Ik heb die group shared nl. niet zelf aangemaakt maar die zal e-smith waarschijnlijk automatisch hebben aangemaakt. Alleen weet ik niet wat voor rechten die groep heeft. Hoe kan ik dat checken?

[Verwijderd]

Om te kijken wie er in een bepaalde groep zitten:
cat /etc/group
of eventueel
cat /etc/group | grep shared

Permissies voor die groep worden dus per bestand en directory opgegeven!!
Om de permissies op die bestanden te bekijken doe je:
ls -al /home/e-smith/files/primary/html

[MinddiggerNL]

Op maandag 07 mei 2001 21:53 schreef nelske het volgende:
Ipchains kan het niet zijn, anders zou je geen 403 krijgen (Connection Refused) van de webserver!

Oh ok...was maar een idee, had geen idee of het kon

Zet anders eens het volgende erin en controleer of er niks conflicterends met deze regels in je httpd.conf staat.

code:

<Directory "/home/e-smith/files/primary/html">
    Options Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Waar moet ik dat ertussen duwen? Die httpd.conf file is zo mega uitgebreid ik zie daar door de bomen het bos niet meer in. zeker niet als linux newbie.

Heb je verder niet toevallig een Virtualhost in je config staan met een andere defaultroot?
Of een bestandje .htaccess waarin toegang wordt geblokeerd!

Geen idee, lijkt me niet. Alle overige subdomeinen doen het alleen het hoofddomein niet! En die file .htaccess daar wordt in httpd.conf wel naar verwezen maar ik heb geen idee waar die staat. Met find / -name .htaccess vind ie niks.

[/quote]Probeer anders eens te telnetten op poort 80 naar je webserver en kijk of de verbinding niet geweigerd wordt.[/quote]

er gebeurt bizar weinig als ik ipv poort telnet poort 80 invul! Als ik gewoon op poort telnet inlog dan doet ie het wel! Wat wil dit zeggen? Volgens mij is mijn servertje behoorlijk gaar

Kijk ook eens in de apache log-files wat daar staat!!

En waar kan ik die vinden?

[MinddiggerNL]

Op maandag 07 mei 2001 22:59 schreef nelske het volgende:
Om te kijken wie er in een bepaalde groep zitten:
cat /etc/group
of eventueel
cat /etc/group | grep shared

Permissies voor die groep worden dus per bestand en directory opgegeven!!
Om de permissies op die bestanden te bekijken doe je:
ls -al /home/e-smith/files/primary/html

Als ik cat /etc/group | grep shared doe krijg ik dit:

shared:x:500:www,admin,public,bas,bastin,dave,fabienne,harry,ine,project,timothee,webmaster,bedaux,cablemadness,ftpserver,intranet,tbastin,systeminfo

Dat met dat ls wist ik inmiddels Dat heb ik van deze zeik inmiddels geleerd hoe je de rechten in kunt stellen. Het is dus toch nog ergens goed voor maar het zou toch wel plezierig zijn als ie nu eens ging meewerken

[Verwijderd]

Stuur die .conf file maar eens op naar me!

[e-mail] , dan kijk ik er wel ff naar

[MinddiggerNL]

graag!

die httpd.conf neem ik aan he? Hoe krijg ik die op mijn pc zodat ik hem kan emailen naar je?

[Verwijderd]

ftp, samba, nfs.
Of je kopieert hem naar een van de directories van de subdomeinen die wel werken en je past de permissies aan zodat ie voor iedereen daar leesbaar is (chmod 644) en gaat er met je browser heen en slaat het op als tekstbestand

[Verwijderd]

Ik kan zo snel niks vreemds vinden in die config-files.
Het enige wat me op viel was dat er wel een servername gedefinieerd was. Als ik me niet vergis kan dit nogal wat problemen opgeven als je met virtualhosts werkt (wat jij doet).
Ik zou dus ook eens proberen om hier commentaar van te maken door er een hekje voor te zetten en apache opnieuw op te starten.

Wel is het schijnbaar zo dat je bij e-smith alles in moet stellen volgens templates en niet direct in die config-file (tenminste dat staat aan het begin van die config) en ik weet niet precies hoe dat werkt met e-smith.

Ik weet wel dat die config nodeloos ingewikkeld is, waardoor er makkelijk foutjes in kunnen sluipen (hoewel ik er zo snel geen heb kunnen vinden buiten een DirectoryIndex die 2 maal gedefinieerd is en eerder genoemd probleem, wil dat natuurlijk niet zeggen dat er geen fouten meer in staan)

Kijk ook eens naar de log-files (aan de config te zien zijn die te vinden onder de directory /etc/httpd (Een beetje een vreemde plaats voor logfiles maar goed))

Als dit alles nog niks oplost, dan moet het haast wel aan de permissies liggen op de bestanden zelf (weet je zeker dat de bestandne worldreadable zijn?).

Tja ik hoop dat je hier wat mee kunt.

[MinddiggerNL]

Op dinsdag 08 mei 2001 00:02 schreef nelske het volgende:
Ik kan zo snel niks vreemds vinden in die config-files.
Het enige wat me op viel was dat er wel een servername gedefinieerd was. Als ik me niet vergis kan dit nogal wat problemen opgeven als je met virtualhosts werkt (wat jij doet).
Ik zou dus ook eens proberen om hier commentaar van te maken door er een hekje voor te zetten en apache opnieuw op te starten.

Dat heb ik dus net geprobeerd maar het heeft wederom niks geholpen.

Wel is het schijnbaar zo dat je bij e-smith alles in moet stellen volgens templates en niet direct in die config-file (tenminste dat staat aan het begin van die config) en ik weet niet precies hoe dat werkt met e-smith.

Ja klopt...er is een template directory waar je de bestanden wel mag veranderen. die overruled ie dan met de originele.

Ik weet wel dat die config nodeloos ingewikkeld is, waardoor er makkelijk foutjes in kunnen sluipen (hoewel ik er zo snel geen heb kunnen vinden buiten een DirectoryIndex die 2 maal gedefinieerd is en eerder genoemd probleem, wil dat natuurlijk niet zeggen dat er geen fouten meer in staan)

Dat vond ik ook al

Kijk ook eens naar de log-files (aan de config te zien zijn die te vinden onder de directory /etc/httpd (Een beetje een vreemde plaats voor logfiles maar goed))

Ik heb er naar gekeken en in de error logfiles staat volgens mij wel het een en ander, alleen weet ik niet wat dat allemaal inhoudt. Ik heb die twee files eens ff naar je gemaild. Misschien dat als je tijd hebt dat je daar eens naar zou kunnen kijken.

Als dit alles nog niks oplost, dan moet het haast wel aan de permissies liggen op de bestanden zelf (weet je zeker dat de bestandne worldreadable zijn?).

Dat moet haast wel. ik heb ze hetzelfde ingesteld als bij die man waar het wel werkt. Hoe precies weet ik uit mijn hoofd niet maar dat staat een paar postings hierboven.

Tja ik hoop dat je hier wat mee kunt.

Helaas heeft het nog niet geholpen maar in ieder geval bedankt voor het nakijken!

[MinddiggerNL]

als ik trouwens cat /etc/group intik krijg ik dit o.a. te zien:

shared:x:500:www,admin,public,bas,bastin,dave,fabienne,harry,ine,project,timothee,
webmaster,bedaux,cablemadness,ftpserver,intranet,tbastin,systeminfo,rob

en

extern:x:5001:admin,www,bas,dave,project,timothee,webmaster,rob

ik neem aan dat die 500 en 5001 de rechten van de groep aangeven? Als dat zo is, dan vermoed ik dus dat de group shared (die eigenaar is van de html dir)een 1 mist die aangeeft dat "others" ook rechten hebben, of heb ik dit verkeerd gezien???

En als dit het is, hoe pas ik dan de rechten aan van die groep?

[Verwijderd]

Op dinsdag 08 mei 2001 09:19 schreef timotheebastin het volgende:
Ik heb er naar gekeken en in de error logfiles staat volgens mij wel het een en ander, alleen weet ik niet wat dat allemaal inhoudt. Ik heb die twee files eens ff naar je gemaild. Misschien dat als je tijd hebt dat je daar eens naar zou kunnen kijken.

Ik heb niks ontvangen hoor!

Helaas heeft het nog niet geholpen maar in ieder geval bedankt voor het nakijken!

Tja dat heb ik dus nog niet kunnen doen

Op dinsdag 08 mei 2001 14:24 schreef timotheebastin het volgende:
als ik trouwens cat /etc/group intik krijg ik dit o.a. te zien:

shared:x:500:www,admin,public,bas,bastin,dave,fabienne,harry,ine,project,timothee,
webmaster,bedaux,cablemadness,ftpserver,intranet,tbastin,systeminfo,rob

en

extern:x:5001:admin,www,bas,dave,project,timothee,webmaster,rob

ik neem aan dat die 500 en 5001 de rechten van de groep aangeven? Als dat zo is, dan vermoed ik dus dat de group shared (die eigenaar is van de html dir)een 1 mist die aangeeft dat "others" ook rechten hebben, of heb ik dit verkeerd gezien???

En als dit het is, hoe pas ik dan de rechten aan van die groep?

Nee!!!!!!!! NIET DOEN.

De eerste entry in /etc/group staat voor de group naam, de 2e voor een eventueel wachtwoord, de 3e (waarom het jou dus gaat), is het GroupID (het getal dat bij de groep hoort; dit heeft niks met rechten te maken, aangezien dat zoals ik al eerder zei, per bestand enn per directory ingesteld wordt).
De 4e entry is om de members van de groep op te geven.

[MinddiggerNL]

Op dinsdag 08 mei 2001 16:29 schreef nelske het volgende:

[..]

Ik heb niks ontvangen hoor!
[..]

Oh, dan ben ik die vergeten te sturen, komen ze er zo aan

Tja dat heb ik dus nog niet kunnen doen

Ik bedoelde het nakijken van de httpd.conf op fouten

Nee!!!!!!!! NIET DOEN.

De eerste entry in /etc/group staat voor de group naam, de 2e voor een eventueel wachtwoord, de 3e (waarom het jou dus gaat), is het GroupID (het getal dat bij de groep hoort; dit heeft niks met rechten te maken, aangezien dat zoals ik al eerder zei, per bestand enn per directory ingesteld wordt).
De 4e entry is om de members van de groep op te geven.

Oké, heb dat ook nog niet gedaan en zal het dan ook maar laten

[MinddiggerNL]

Heb je nog een optie?

[Verwijderd]

Blijkbaar heeft apache een paar keer opnieuw opgestart terwijl er nog een apache-server draaide, getuige de volgende regel:

[crit] (98)Address already in use: make_sock: could not bind to port 80

Apache moet wel volledig afgesloten zijn als hij opnieuw opgestart wordt, anders kan hij namelijk niet aan die poort (80) binden en zal de nieuwe configuratie dus ook niet van kracht zijn, maar zulllen bestanden geserveerd worden door de nog reeds draaide apache server. ("killall -9 httpd" doet wonderen:))

Verder geeft hij in de logfiles aan dat file-permissions de oorzaak zijn van het niet mogen benaderen van die website.
Dit kunnen dus 2 dingen zijn; de permissies op de bestanden/directories zelf zijn niet goed of de toegangsrechten in httpd.conf staan niet goed.

Ik heb zelf de fout kunnen reproduceren door eerst een bestand op mijn server aan te maken met geen leesrechten voor iedereen.
Onmiddelijk verscheen er een precies dezelfde foutmelding als jij had, namelijk:

(13)Permission denied: file permissions deny server access:

Maar goed, aangezien alle bestanden in jouw directory inmiddels world-readable zijn, kan het dat eigenlijk niet zijn.

Toen heb ik de documentroot (is een directory en dus geen bestand!) zelf maar eens niet world-executable gemaakt (dat moet hij natuurlijk wel zijn evenals alle subdirs die die directory heeft (dit geld dus niet voor bestanden, maar alleen voor directories!!!)). En wat denk je?
Precies dezelfde fout als bovenstaande fout.
Ik zou dus maar eens heel goed kijken of de DocumentRoot zelf wel world-executable is (chmod 775 /home/e-smith/files/primary/html).

Als ie dat wel is en het ligt ook niet aan de andere bestands permissies, dan zou ik het toch maar in access-restrictions zoeken en tijdelijk voor de virtualhost waar het om gaat alle regels, waar maar "Deny from All" in staat van commentaar voorzien. Deze regels hoeven er voor die virtuele host toch niet te staan, aangezien die virtuele host voor heel internet toegankelijk moet zijn (toch?).

Tja als het dan nog niet werkt, dan zou ik het zo snel niet meer durven zeggen eigenlijk.

[MinddiggerNL]

Op dinsdag 08 mei 2001 18:02 schreef nelske het volgende:
Blijkbaar heeft apache een paar keer opnieuw opgestart terwijl er nog een apache-server draaide, getuige de volgende regel:
[..]

Apache moet wel volledig afgesloten zijn als hij opnieuw opgestart wordt, anders kan hij namelijk niet aan die poort (80) binden en zal de nieuwe configuratie dus ook niet van kracht zijn, maar zulllen bestanden geserveerd worden door de nog reeds draaide apache server. ("killall -9 httpd" doet wonderen:))

Ik heb nu achtereenvolgens "killall -9 httpd" en /etc/rc.d/init.d/httpd restart getikt. Bij het afsluiten van httpd zegt ie dan "failed" wat denk ik ook logisch is en vervolgens "ok" bij het opnieuw opstarten van httpd. Dan doet de site het nog niet.

Verder geeft hij in de logfiles aan dat file-permissions de oorzaak zijn van het niet mogen benaderen van die website.
Dit kunnen dus 2 dingen zijn; de permissies op de bestanden/directories zelf zijn niet goed of de toegangsrechten in httpd.conf staan niet goed.

Ik heb zelf de fout kunnen reproduceren door eerst een bestand op mijn server aan te maken met geen leesrechten voor iedereen.
Onmiddelijk verscheen er een precies dezelfde foutmelding als jij had, namelijk:
[..]

Maar goed, aangezien alle bestanden in jouw directory inmiddels world-readable zijn, kan het dat eigenlijk niet zijn.

Toen heb ik de documentroot (is een directory en dus geen bestand!) zelf maar eens niet world-executable gemaakt (dat moet hij natuurlijk wel zijn evenals alle subdirs die die directory heeft (dit geld dus niet voor bestanden, maar alleen voor directories!!!)). En wat denk je?
Precies dezelfde fout als bovenstaande fout.
Ik zou dus maar eens heel goed kijken of de DocumentRoot zelf wel world-executable is (chmod 775 /home/e-smith/files/primary/html).

Ik heb dus na bovenstaande twee commando''s nog eens ff gekeken naar die rechten en toch maar voor de zekerheid
chmod 775 /home/e-smith/files/primary/html
en
chmod 775 /home/e-smith/files/primary/html/*
gedaan en dit heeft wederom niet mogen baten!

Als ie dat wel is en het ligt ook niet aan de andere bestands permissies, dan zou ik het toch maar in access-restrictions zoeken en tijdelijk voor de virtualhost waar het om gaat alle regels, waar maar "Deny from All" in staat van commentaar voorzien. Deze regels hoeven er voor die virtuele host toch niet te staan, aangezien die virtuele host voor heel internet toegankelijk moet zijn (toch?).

Ja, ik weet niet of je die primary ook een virtual host kunt noemen maar ze moeten allemaal via internet zichtbaar zijn alleen die intranet ibay zoals dat heet bij e-smith hoeft dat niet te zijn.

Volgens mij had ie het nu toch moeten doen he? Na die chmod dinges en die full restart van de webserver. Ik vermoed dus dat er toch wat fout gaan in die httpd.conf maar ik begrijp niet zo goed wat je bedoeld met deze zin:

dan zou ik het toch maar in access-restrictions zoeken en tijdelijk voor de virtualhost waar het om gaat alle regels, waar maar "Deny from All" in staat van commentaar voorzien

Tja als het dan nog niet werkt, dan zou ik het zo snel niet meer durven zeggen eigenlijk.

Dat punt had ik al eerder bereikt

[Verwijderd]

Ja voor alle regeles waar maar "deny from all" staat een hekje (#) zetten.
Dan moet ie het gegarandeerd doen.

Als je het maar niet doet voor die ene site die je op je intranet gebruikt.

Ik moet nu weg, maar succes ermee nog maar een keer

[MinddiggerNL]

Op dinsdag 08 mei 2001 20:01 schreef nelske het volgende:
Ja voor alle regeles waar maar "deny from all" staat een hekje (#) zetten.
Dan moet ie het gegarandeerd doen.

Als je het maar niet doet voor die ene site die je op je intranet gebruikt.

Ik moet nu weg, maar succes ermee nog maar een keer

Ik heb httpd.conf geopend en binnen met /deny gezocht met vi binnen die file naar alle regels die begonnen met "deny from all" en er een # voor gezet. Toen die file gesaved en apache wederom geherstard. En wat denk je??? Hij doet het nog niet!!!!!

Ik snap er nu echt geen fluit meer van en jij waarschijnlijk ook niet, of wel?

Ik denk dat ik toch maar komend weekend ff een herinstallatie van e-smith ga doen want dit gaat iets té lang duren.
Of je moet nog een andere oplossing hebben Of een andere linux guru misschien?

[MinddiggerNL]

Hij doet het weer!

Ik heb toevallig vandaag op het e-smith.org forum een topic gezien waar iemand vroeg wat ie moest doen nadat ie zijn admin pagina''s kwijt was na een upgrade. Hij kreeg identieke foutmeldingen als mij.

Iemand deed de volgende suggestie (citaat):

Have you tried telling e-smith that you have performed an upgrade? If you haven''t try:
/sbin/e-smith/signal-event post-upgrade
/sbin/e-smith/signal-event reboot

This, amongst other things, rebuilds a lot of the access-control files from templates.

Dit heeft bij mij dus ook geholpen en mijn website is nu dus weer online Was eigenlijk wel handig geweest als ze dat ergens in de handleiding hadden gezet want ze suggereren dat je maar heel af en toe voor bijv. het veranderen van de system name hoeft te resetten, maar zelfs een reset hielp in mijn geval niet!

Ik post dit dus nu ff zodat iedereen die hiermee problemen krijgt in e-smith een mogelijke oplossing heeft.

Timothée