Scoutnet vzw

Iedereen gaat een directory 'public_html' krijgen

Waarom???
- Om andere privileges toe te kennen aan deze of de andere directorys?
- Is het de bedoeling om ook standaard een paswoord beveiligd deel te maken bvb. 'private_html'?
- Verandert het relatieve pad naar bvb. cgi-bin?
- Is er iets dat we zelf kunnen doen om de omzetting vlotter te laten verlopen?

een stevige linker,

Caygull

public_html is een "standaard" dir in de *nix wereld. Als de webserver een request krijgt voor bijvoorbeeld http://dezehost.be/~someuser dan zal die in de home dir van someuser gaan zoeken naar /public_html (of iets anders, al naar gelang).
Waarschijnlijk is deze wijziging er om later makkelijker de overstap naar suExec te kunnen maken. 't Is dus voor een goed doel :)

neen

das dan alvast een mogelijkheid.

neen

al ne keer denken waar er eventueel wijzigingen nodig zullen zijn...

Het grootste voordeel van deze directory is dat je nu ook files 'buiten' je website kan plaatsen.
Een subdomein in een eigen virtualhost laten draaien. (pro-account)
of een tweede domeinnaam onder hetzelfde account.

Zou er kunnen gewacht worden met die omschakeling tot na de examens? Ik heb nu geen tijd om alle code te checken...

Hiermee worden de mailinglijsten ook beveiligd tegen toegang via het web, maar dat zou ook al opgelost zijn met het nieuwe maillijstsysteem dat al een tijdje op komst is.

Misschien dat de logs dan weer kunnen verhuizen naar de dir van de accounts?
Tweede domeinnaam is inderdaad een handig nieuwe optie.
Bij mij lukt het beter tijdens de examens dan tijdens de vakantie.

De html-root blijft dezelfde, voor afbeeldingen op de pagina's ofzo, voor de gebruikers blijven alle pagina's op dezelfde plaats staan, / vooraan je path blijft nog altijd in de juiste dir terecht komen.
De php-root wordt /scoutnet/users/groepsnaam/public_html
Volgens mij zijn het enkel diegene die ergens een dergelijke link staan hebben die iets zullen moeten aanpassen. Hopelijk is dit één variabele zodat je dat maar op één plaats moet aanpassen, anders is het nu het moment om dat te doen.

ik denk dat 90% van jullie niets zal moeten wijzigen.

Wat we met de log files gaan doen, ligt nog niet vast.

De omschakeling gebeurt account per account. Je zal dus nog op de hoogte gebracht worden wanneer precies we deze wijziging doorvoeren voor jouw account. Als de datum die wij daar dan voorstellen niet past, stel dan gewoon een andere datum voor.

(maar hou er rekening mee dat we deze wijziging er voor iedereen veel rapper willen doorkrijgen dan bv. 'register globals off' )

oh ja, er is ook een tellertje voorzien waar je onze vorderingen kan opvolgen
[deze site links onderaan]

Bedankt voor alle reacties, t' is mij al een beetje duidelijker.

Caygull

Ik ben ook wel niet zo te vinden voor de timing van het jaar, 'tzijn examens weet je wel...

Ik hoop dat er niets fout loopt en vooral als er iets fout is, dat het niet al te veel werk zal zijn...

een php-forum op de site, blijft die dan nog werken? of moet je daar dan ook gewoon in het admin-panel daar die die public html aan toevoegen?

Geen probleem. Aan het phpBB(?)-forum hoeft niets aangepast te worden. Bij de meeste accounts moet er trouwens zo goed als niks veranderen. Enkel in htaccess-bestanden of een cronjob kan het zijn dat er wat moet worden aangepast. En zelfs dan doet Scoutnet dat waarschijnlijk zelf.

Onze omschakeling vorige maandag is zo goed als vlekkeloos verlopen. Ondertussen is het *public_html*-tellertje de *register_globals* voorbijgestoken. Mooi zo!

Jorisp, nog veel succes ermee!

To

Helaba, er is nog volk bezig met de omschakeling hoor Joris heeft een handig script geschreven dat het werk serieus makkelijker maakt en ja, we houden ook rekening met oa. cronjobs, .htaccess, ... en andere leuke verrassingen. Indien er toch nog foutjes verschijnen, laat ons deze dan zeker weten zodat we leren voor de sites die nog moeten komen.

Oeps, s(n)orry! Leve Doomer!

To

ps: in onze cgi-bin stond een .htaccess die niet werd aangepast. Ofwel was ik jullie gewoon vóór natuurlijk (de cronjob was wel aangepast).

de crontab was bij ons dan weer niet aangepast, voor de rest ook geen probs buiten een path in phpBB dat ikzelf vergeten was.
(voor een standaard installatie van phpBB is er geen probleem, maar als je er zelf aan prutst... tja )

Ik weet niet of het komt door de omschakeling, maar ik vermoed het:

Ik heb onlangs gemerkt dat alle mail aliassen weg zijn, het bestand is gewoon leeg? Geen ramp hoor, dat maken we wel terug aan. Wat ik ook gemerkt heb en wat wel een beetje ambetanter is is ons fotoalbum. Onze site werkt met een postnuke omgeving. Voor de foto's gebruiker we http://gallery.sourceforge.net/

Wanneer er een nieuw (sub)album aangemaakt wordt verschijnt de nieuwe map er wel. De foto's worden ook in die map gezet. Maar er is een probleem met de permissies waardoor deze mappen (albums) niet zichtbaar worden. Blijkbaar krijgen alle bestanden aangemaakt door de gallery als rechten 644. Sommige bestanden moeten eigenlijk de rechten 777 krijgen. We hebben geen aanpassingen gedaan aan onze gallery dus ik weet niet of we het probleem in onze config moeten zoeken (de config geeft trouwens overal ok aan).

Zijn er nog mensen die dit probleem hebben?

er is een verschil tussen een album aangemaakt via de website (user =apache)

en

een album die je bv. via ftp naar de server kopieerde (user = snxxxx)

ge zult dus aan beide andere permissies moeten geven.