[Debian] Setup voor een server

Pagina: 1
Acties:
  • 132 views sinds 30-01-2008
  • Reageer

  • rvdven
  • Registratie: November 2006
  • Laatst online: 03-01 07:24
Ik heb nu ongeveer een jaartje thuis een servertje staan om wat mee te experimenteren en om er van te leren. Daarom heb ik ook al meerdere setups gehad die telkens wat flexibeler werden. Op het moment draai ik het volgende:
Apache2 + php (nu 4, wordt 5 als etch stable wordt);
MySQL (later misschien nog wat PostgreSQL om dat eens te bekijken);
ProFTPd met authenticatie via een MySQL database;
Postfix + Courier pop3; ook met MySQL naar dit voorbeeld;

Ik heb met deze setup echter nog een paar problemen: om een virtual-host aan te maken bij Apache moet ik een bestand aanmaken, dat invullen, dan a2ensite uitvoeren en dan apache reloaden. Dat is geen heisa, aangezien het zelden hoeft. Maar toch heb ik liever iets flexibelers.
Daarnaast is de eigenaar van alle bestanden die via ProFTPd ge-upload worden dezelfde (ftpuser), wat volgens mij een veiligheidsrisico met zich mee brengt aangezien de ene user dan met z'n php-script een ander php-script kan aanpassen, of kan uitlezen (bijvoorbeeld voor het wachtwoord van de db)

Met wat rondkijken ben ik Ldap tegen gekomen. Ik had er al wel eens van gehoord en ik zag dat je er ook virtuele hosts van apache mee kunt maken dmv. mod-vhost-ldap. Alhoewel ik me hier nog niet verder in heb verdiept. Ook zag ik dat het mogelijk was om Ldap te gebruiken voor mail en FTP. Daarnaast zou het mogelijk moeten zijn om het te gebruiken voor het login systeem van de server zelf. Ik had daar nog niet echt verder naar gekeken maar als het hiermee mogelijk is om systeem-users en -groups aan te maken, dan is het rechtenprobleem van apache ook verdwenen.

Ik vroeg me af of dit ook echt zo werkt en of jullie misschien een andere (leukere/betere) mogelijkheid hebben om dit te laten werken (iets met chrooten ofzo?). En misschien hebben jullie nog wel andere tips tav. het hebben van een server?

Alvast bedankt.

PS. Ik heb wel al gezocht voor een antwoord met echt een duidelijk iets had ik niet kunnen vinden. Vandaar dat ik het hier maar vraag.

  • Japidoff
  • Registratie: November 2001
  • Laatst online: 16-01 18:20
eeven over apache, ik ken debian niet, maar op mijn fedora, edit ik gewoon httpd.conf. hoe flexibel wil je t hebben? of mis ik dan wat?

en proftpd moet ook gewoon elke user zn eigen files kunnen chowen (volgens mij kan elke ftp server dat..) staat t niet in de handleiding?

edit:

dat chroot is m wel jah, je moet zorgen dat iedere user zn eigen root heeft, en niet hoger kan...

ldap heb ik geen ervaring mee, maar het is iig een protocol, en niet echt een programma, gaat meer richting windows domain controller d8 ik

ik draait ook al een tijdje php5 / mysql, en ik kan je vertellen dat hij aardig stabiel is hoor!
heb toch al aardig wat geprutst met passtrough/gd/cross-domain login en ik heb nog geen rare dingen gezien...

[ Voor 48% gewijzigd door Japidoff op 23-02-2007 21:20 ]

gang is alles


  • rvdven
  • Registratie: November 2006
  • Laatst online: 03-01 07:24
Japidoff schreef op vrijdag 23 februari 2007 @ 21:10:
eeven over apache, ik ken debian niet, maar op mijn fedora, edit ik gewoon httpd.conf. hoe flexibel wil je t hebben? of mis ik dan wat?
Bij apache 1.3 kun je inderdaad httpd.conf aapassen, dit kan bij apache2 ook, alhoewel daar de algemene manier is om een bestandje aan te maken in de sites-available map en dan deze te activeren met a2ensite <sitenaam>, waarna hiervan een symbolische link wordt gemaakt in de sites-enabled map. Dit systeem is op zich prima, maar ik vroeg me af of `professionele' sites dit ook gebruiken. Aangezien het maken en verwijderen van config-bestandjes me niet de ideale manier lijkt. Al helemaal niet als het gelijk moet zijn op een aantal servers.

Dit is enkel een vermoeden, echt duidelijkheid heb ik daar nooit in gehad, alleen Ldap (of misschien een db) lijkt me wat dat betreft handiger aangezien dat te benaderen is vanuit bijvoorbeeld PHP (het bestandssysteem natuurlijk ook, maar dan moet je root-privileges hebben wil je die bestanden aanpassen)
en proftpd moet ook gewoon elke user zn eigen files kunnen chowen (volgens mij kan elke ftp server dat..) staat t niet in de handleiding?
Ik heb niet voor iedereen die m'n systeem gebruikt (dat zijn er maar een paar) ook een eigen systeemaccount. Ik heb enkel een naam in de db voor ProFTPd, een virtual host voor apache en indien nodig ook een naam in de db voor de mail. Anders kon ik inderdaad chownen, maar ik weet niet of het een goede oplossing is om voor ieder domein een eigen systeem-user aan te maken. Zoals ik hierboven ook al zei: ik weet niet hoe dat bij `de profs' gaat.
ldap heb ik geen ervaring mee, maar het is iig een protocol, en niet echt een programma, gaat meer richting windows domain controller d8 ik
Volgens mij is het inderdaad een protocol, als server is er iets als slapd ofzo. Onderdeel van OpenLdap meen ik. Maar of het voor windows domain is, dat wist ik niet. Ik meen dat het een algemeen directory protocol is.
ik draait ook al een tijdje php5 / mysql, en ik kan je vertellen dat hij aardig stabiel is hoor!
heb toch al aardig wat geprutst met passtrough/gd/cross-domain login en ik heb nog geen rare dingen gezien...
Ik heb ook geen problemen met php5 hoor, het is alleen dat deze niet in de standaard repositries van Sarge zitten, en aangezien Etch toch binnenkort uit komt wacht ik daar wel op. Natuurlijk kan ik backports gebruiken, maar ik heb toch genoeg aan php4 op het moment.

  • smesjz
  • Registratie: Juli 2002
  • Niet online
rvdven schreef op vrijdag 23 februari 2007 @ 21:05:
Ik heb nu ongeveer een jaartje thuis een servertje staan om wat mee te experimenteren en om er van te leren. Daarom heb ik ook al meerdere setups gehad die telkens wat flexibeler werden. Op het moment draai ik het volgende:
Apache2 + php (nu 4, wordt 5 als etch stable wordt);
MySQL (later misschien nog wat PostgreSQL om dat eens te bekijken);
ProFTPd met authenticatie via een MySQL database;
Postfix + Courier pop3; ook met MySQL naar dit voorbeeld;

Ik heb met deze setup echter nog een paar problemen: om een virtual-host aan te maken bij Apache moet ik een bestand aanmaken, dat invullen, dan a2ensite uitvoeren en dan apache reloaden. Dat is geen heisa, aangezien het zelden hoeft. Maar toch heb ik liever iets flexibelers.
Ik gebruik zelf mod_vhost_alias (http://httpd.apache.org/docs/2.2/vhosts/mass.html) en dat werkt uitstekend als je vhosts gebruikt die hetzelfde zijn qua structuur. In mijn geval is dat /var/www/{domain.tld}/web

Ik had vroeger een Perl script dat als 404 handler zelf die structuur aanmaakte als 'www.blaat.nl' werd aangeroepen maar de bijbehorende directory bestond nog niet. Daarbij werd gekeken of blaat.nl wel in de eigen DNS-server stond voordat het werd aangemaakt.
Daarna werd mailtje gestuurd dat map was aangemaakt.

Nu gebruik ik dat niet meer en maak ik zelf via FTP (vsftpd) de directory structuur aan. Via mod_rewrite wordt www.blaat.nl/stats herschreven naar www.blaat.nl/cgi-bin/awstats.pl?config=blaat en voor ontwikkeldoeleinden herschrijft mod_rewrite blaat.testdomein.nl naar /var/www/blaat.nl/web zodat 'onderwater' werken ook mogelijk is.

Dit werkt onafhankelijk van je distro, ik gebruik zelf toevallig Debian. Om in jouw geval LDAP of SQL op te zetten voor Apache lijkt me voor jouw setup een beetje te omslachtig. mod_vhost_alias werkt al vanaf apache 1.3 en gebruik het ook gewoon met apache 2.2

Met Lighttpd (alternatief voor Apache) kan je zoiets vrij simpel doen: http://trac.lighttpd.net/trac/wiki/Docs%3AModMySQLVhost

  • burne
  • Registratie: Maart 2000
  • Niet online

burne

Mine! Waah!

rvdven schreef op vrijdag 23 februari 2007 @ 22:08:
Bij apache 1.3 kun je inderdaad httpd.conf aapassen, dit kan bij apache2 ook, alhoewel daar de algemene manier is om een bestandje aan te maken in de sites-available map en dan deze te activeren met a2ensite <sitenaam>,
Da's een debianisme, en geen gewoonte onder apache2.
waarna hiervan een symbolische link wordt gemaakt in de sites-enabled map. Dit systeem is op zich prima, maar ik vroeg me af of `professionele' sites dit ook gebruiken.
Het wisselt. Profi hostingboeren gebruiken een provisioning-systeem. De kleintjes vaak iets van ensim, cpanel, plesk etc, en de grotere hebben vaak eigen systemen. Die schrijven ofwel een grote config die geinclude wordt, of een verzameling kleine bestandjes (een per site of een per klant).
Aangezien het maken en verwijderen van config-bestandjes me niet de ideale manier lijkt. Al helemaal niet als het gelijk moet zijn op een aantal servers.
Het is juist 'goedkoper' (minder werk) om een berg bestandjes te schrijven of weer weg te halen dan een enorme lap config bij te werken. En omdat het geautomatiseert gebeurd is het geen probleem dat op een berg machines te doen. Of om per server een subtiel verschil aan te brengen, bijvoorbeeld om zaken als loadbalancing te regelen.
maar ik weet niet of het een goede oplossing is om voor ieder domein een eigen systeem-user aan te maken. Zoals ik hierboven ook al zei: ik weet niet hoe dat bij `de profs' gaat.
Het is een voorwaarde voor grootschalig hosten. Je wilt niet dat klanten elkaars bestanden gaan aanpassen, opzettelijk of per ongeluk.
Volgens mij is het inderdaad een protocol, als server is er iets als slapd ofzo.
LDAP is een database voor read-only tekst-data. Schrijven kan natuurlijk, maar LDAP is erg traag en erg beperkt qua schrijven. Je stelt vragen als 'wat is de homedir van gebruiker kees' en je krijgt een antwoord in de vorm van een tekststring. LDAP in de pure opzet bevat 'directory-data'. Een typisch LDAP-record (gegapt van wikipedia) ziet er zo uit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
dn: cn=John Doe,dc=example,dc=com
 cn: John Doe
 givenName: John
 sn: Doe
 telephoneNumber: +1 888 555 6789
 telephoneNumber: +1 888 555 1234
 mail: john@example.com
 manager: cn=Barbara Doe,dc=example,dc=com
 objectClass: inetOrgPerson
 objectClass: organizationalPerson
 objectClass: person
 objectClass: top

Het LDAP-artikel op de Engelse wikipedia geeft je een aardige intro.

I don't like facts. They have a liberal bias.


  • rvdven
  • Registratie: November 2006
  • Laatst online: 03-01 07:24
burne schreef op zaterdag 24 februari 2007 @ 00:56:
[...]

Da's een debianisme, en geen gewoonte onder apache2.
Ok, jammer eigenlijk, want het werkt wel makkelijk en overzichtelijk :)
[...]

Het wisselt. Profi hostingboeren gebruiken een provisioning-systeem. De kleintjes vaak iets van ensim, cpanel, plesk etc, en de grotere hebben vaak eigen systemen. Die schrijven ofwel een grote config die geinclude wordt, of een verzameling kleine bestandjes (een per site of een per klant).

[...]

Het is juist 'goedkoper' (minder werk) om een berg bestandjes te schrijven of weer weg te halen dan een enorme lap config bij te werken. En omdat het geautomatiseert gebeurd is het geen probleem dat op een berg machines te doen. Of om per server een subtiel verschil aan te brengen, bijvoorbeeld om zaken als loadbalancing te regelen.
Ik ken die panels inderdaad ook, maar ik was vooral benieuwd hoe die eigenlijk werken (een beetje knoppendrukken kan `iedereen' :P) Maar ze maken dus gewoon bestandjes aan, dan zal ik daar maar eens naar gaan kijken.
[...]

Het is een voorwaarde voor grootschalig hosten. Je wilt niet dat klanten elkaars bestanden gaan aanpassen, opzettelijk of per ongeluk.
Dat was inderdaad waar ik ook mee zat. Maar dan kan ik dus het beste een scriptje schrijven dat bij het toevoegen van een `klant' een systeem-user aanmaakt? Hoe kan ik dat dan het beste doen met meerdere mail- en ftpaccounts per `klant'? Ik neem aan dat iets als MySQL daar het beste voor werkt als ik daarmee de alliassen link aan het user-id van de klant waar ze bij horen (bij ftp)
[...]

LDAP is een database voor read-only tekst-data. Schrijven kan natuurlijk, maar LDAP is erg traag en erg beperkt qua schrijven. Je stelt vragen als 'wat is de homedir van gebruiker kees' en je krijgt een antwoord in de vorm van een tekststring. LDAP in de pure opzet bevat 'directory-data'. Een typisch LDAP-record (gegapt van wikipedia) ziet er zo uit:
code:
1
[...]

Het LDAP-artikel op de Engelse wikipedia geeft je een aardige intro.
Dat zal ik dan maar eens gaan bekijken :)

  • rvdven
  • Registratie: November 2006
  • Laatst online: 03-01 07:24
smesjz schreef op zaterdag 24 februari 2007 @ 00:34:
[...]


Ik gebruik zelf mod_vhost_alias (http://httpd.apache.org/docs/2.2/vhosts/mass.html) en dat werkt uitstekend als je vhosts gebruikt die hetzelfde zijn qua structuur. In mijn geval is dat /var/www/{domain.tld}/web

Ik had vroeger een Perl script dat als 404 handler zelf die structuur aanmaakte als 'www.blaat.nl' werd aangeroepen maar de bijbehorende directory bestond nog niet. Daarbij werd gekeken of blaat.nl wel in de eigen DNS-server stond voordat het werd aangemaakt.
Daarna werd mailtje gestuurd dat map was aangemaakt.
Dat ziet er ook wel uit als een mooie oplossing, alhoewel ik denk ik toch maar losse bestandjes ga gebruiker per vhost.
Nu gebruik ik dat niet meer en maak ik zelf via FTP (vsftpd) de directory structuur aan. Via mod_rewrite wordt www.blaat.nl/stats herschreven naar www.blaat.nl/cgi-bin/awstats.pl?config=blaat en voor ontwikkeldoeleinden herschrijft mod_rewrite blaat.testdomein.nl naar /var/www/blaat.nl/web zodat 'onderwater' werken ook mogelijk is.
Mooie oplossing voor awstats, die ga ik ook gebruiken :) Maar wat bedoel je precies met `onderwater' werken?
Dit werkt onafhankelijk van je distro, ik gebruik zelf toevallig Debian. Om in jouw geval LDAP of SQL op te zetten voor Apache lijkt me voor jouw setup een beetje te omslachtig. mod_vhost_alias werkt al vanaf apache 1.3 en gebruik het ook gewoon met apache 2.2

Met Lighttpd (alternatief voor Apache) kan je zoiets vrij simpel doen: http://trac.lighttpd.net/trac/wiki/Docs%3AModMySQLVhost
Ldap is inderdaad overkill, maar eigenlijk is het gebruik van MySQL op mijn schaal dat ook. Het gaat mij dan ook puur om het leerproces dat er bij komt kijken.

  • smesjz
  • Registratie: Juli 2002
  • Niet online
rvdven schreef op zaterdag 24 februari 2007 @ 13:02:
[...]

Dat ziet er ook wel uit als een mooie oplossing, alhoewel ik denk ik toch maar losse bestandjes ga gebruiker per vhost.
Dan moet je nog steeds apache gracefullen? Per vhost een aparte config lijkt me niet handig. mod_vhost_alias is juist erg geschikt voor upscalen. Je kan vhost specifieke zaken nog steeds apart opnemen in je config.
Mooie oplossing voor awstats, die ga ik ook gebruiken :) Maar wat bedoel je precies met `onderwater' werken?
Ok, stel je bent bezig voor groteklant.nl die zijn website nu nog bij provider X heeft staan. Als jij de nieuwe site van groteklant.nl klaar hebt wordt de DNS aangepast (of het domein wordt verhuisd).
Je kan alle voorbereidingen dan al treffen door de nieuwe site gewoon te maken in /var/www/groteklant.nl . Echter, om hem te bekijken (en de klant de mogelijkheid te geven om er naar te kijken cq te vullen) kan je onderwater werken op http://groteklant.jouwdomein.nl

mod_rewrite herschrijft dus groteklant.jouwdomein.nl naar /var/www/groteklant.nl

Het fijne is namelijk dat, wanneer de site verhuisd wordt of DNS wordt aangepast, jij niks hoeft te veranderen en zowel het oude als het nieuwe adres blijft werken.
[/quote]

[ Voor 6% gewijzigd door smesjz op 24-02-2007 13:19 . Reden: quote fix ]


  • rvdven
  • Registratie: November 2006
  • Laatst online: 03-01 07:24
smesjz schreef op zaterdag 24 februari 2007 @ 13:18:
[...]


Dan moet je nog steeds apache gracefullen? Per vhost een aparte config lijkt me niet handig. mod_vhost_alias is juist erg geschikt voor upscalen. Je kan vhost specifieke zaken nog steeds apart opnemen in je config.
Dat is waar, ik zal d'r nog maar eens over denken wat ik nou ga doen.
mod_rewrite herschrijft dus groteklant.jouwdomein.nl naar /var/www/groteklant.nl

Het fijne is namelijk dat, wanneer de site verhuisd wordt of DNS wordt aangepast, jij niks hoeft te veranderen en zowel het oude als het nieuwe adres blijft werken.
Ah zo, dat is wel handig inderdaad. Maak je dan per klant een record aan voor de rewrite? Aangezien je toch niet zeker kunt weten of het naar /var/www/groteklant.nl of /var/www/groteklant.com moet gaan kun je er niet gewoon .nl achter plakken?

  • smesjz
  • Registratie: Juli 2002
  • Niet online
rvdven schreef op zondag 25 februari 2007 @ 11:16:
[...]

Dat is waar, ik zal d'r nog maar eens over denken wat ik nou ga doen.

[...]

Ah zo, dat is wel handig inderdaad. Maak je dan per klant een record aan voor de rewrite? Aangezien je toch niet zeker kunt weten of het naar /var/www/groteklant.nl of /var/www/groteklant.com moet gaan kun je er niet gewoon .nl achter plakken?
Ik heb een wildcard record voor blaat.nl . De meeste klanten hebben zowel de .nl als de .com/.de/.be waarbij de laatste gewoon via een Location header worden doorgestuurd naar de goede pagina. Dat wildcard record heeft dus een ander IP dan 'www.groteklant.nl', zodat ik mod_rewrite niet bij ieder request gebruik omwille van performance redenen.

Een symlink gebruik ik nu om groteklant.com aan groteklant.nl te hangen tijdens het ontwikkelen. Maar ook dat is wel op te lossen mod_rewrite, maar dat wil ik bewust simpel houden.
Die onder water versie (groteklant.blaat.nl) wordt ook nog gebruikt indien de klant www.groteklant.nl niet kan of wil aanpassen. Dit is bijvoorbeeld het geval indien er ook nog een /intranet of /webmail e.d. op die machine draait.
Door die rewrite kan ik gewoon /var/www/groteklant.nl blijven gebruiken en hoef dus geen rare fratsen uit te halen door een per vhost config aan te houden.

  • burne
  • Registratie: Maart 2000
  • Niet online

burne

Mine! Waah!

smesjz schreef op zaterdag 24 februari 2007 @ 13:18:
Dan moet je nog steeds apache gracefullen?
Da's toch geen punt? Je trekt in het script wat apache restart een doos uit de pool van de loadbalancer, herstart z'n apache, en zet 'm weer in de pool. Geen gebruiker die het ooit merkt. mod_rewrite wordt een volstrekte draak met een serieus aantal domeinen omdat *ieder* request een zoekactie in een linked list met rewrites oplevert. Een beetje website heeft al snel 40 elementen op een pagina, en iedere keer voor iedere pagina een paar duizend regels afzoeken kost bakken CPU. mod_rewrite-hash is voor zover ik weet nooit een succes geworden. mod_rewrite is het dupliceren van data die je al hebt op een andere plek in je geheugen en dat schaalt volstrekt niet. Je moet een Host: in een pad vertalen, en dat kun je het beste op de meest directe manier beschikbaar doen. In twee stappen vertalen 'is just plain silly'.

Even voor de context: ik spreek vanuit het perspectief van een hoster met 200.000 domeinnamen en gemiddeld 2000 actieve sites op een machine. Voor m'n eigen machine (met 15 sites) heb ik gewoon 1 platte tekstfile, meer omdat ik lui ben dan om enige andere reden.

I don't like facts. They have a liberal bias.


  • rvdven
  • Registratie: November 2006
  • Laatst online: 03-01 07:24
burne schreef op zondag 25 februari 2007 @ 14:23:
[...]

Da's toch geen punt? Je trekt in het script wat apache restart een doos uit de pool van de loadbalancer, herstart z'n apache, en zet 'm weer in de pool. Geen gebruiker die het ooit merkt.
En wat als er nu geen pool is? Merkt de gebruiker er dan meer van dan dat enkel de pagina enkele seconden langer laadt? Want voor zover ik me meen te herinneren blijven php sessies gewoon werken zodat klanten gewoon ingelogd zouden blijven.

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
rvdven schreef op zondag 25 februari 2007 @ 11:16:
Ah zo, dat is wel handig inderdaad. Maak je dan per klant een record aan voor de rewrite? Aangezien je toch niet zeker kunt weten of het naar /var/www/groteklant.nl of /var/www/groteklant.com moet gaan kun je er niet gewoon .nl achter plakken?
Dat kan toch gewoon (simpeler) met ServerAlias?

  • smesjz
  • Registratie: Juli 2002
  • Niet online
Olaf van der Spek schreef op dinsdag 27 februari 2007 @ 18:38:
[...]

Dat kan toch gewoon (simpeler) met ServerAlias?
Als veel hosts hebt die identiek zijn qua structuur kan je beter mod_vhost_alias gebruiken zodat je geen per vhost config hoeft te hebben. Een symlink zorgt er voor dat je geen (graceful) herstart hoeft te doen.

Maar een NameVirtualHost container kan je natuurlijk altijd gebruiken om Apache wat te helpen.
Pagina: 1