Onderwerp: mod_ruid en webmail rechten

Ik ben niet goed in scripting, had dus wel het nodige uitgezet, maar durfde het alleen niet aan om die datatask.queu regel weg te halen.

Php is compiled als CLI. Ik heb de set_permissions laten lopen op zowel email alsook op userdirs. Php safe mode staat ook uit.
Ik heb zelfs de hele squirrelmail weggehaald en middels ./build update en ./build squirrelmail weer opnieuw geinstalleerd, nog steeds hetzelfde probleem.

@T. Bloo: Nee dat het ik nog niet geprobeerd , wel heb ik eens alle files op owner webapps gezet i.p.v. apache:webapps, maar wilde de security niet compromiteren door meer rechten te geven op bestanden. En als het bij iedereen goed werkt met de normale instellingen moet dat bij ons toch ook zo kunnen? Dat is wat ik er zo vreemd aan vind.

Even een frappant detail. Het begon me vannacht te irriteren dus heb ik Roundcube maar weer eens geinstalleerd. Deze werkte onmiddellijk goed, zonder ook maar een enkel probleem of welke aanpassing dan ook.

De klanten kunnen dus weer webmailen maar met Roundcube.
Het euvel ligt dus ergens aan squirrelmail, maar waar en waarom, dat maakt me nu wel nieuwsgierig.

Al geprobeerd om via ./build het opnieuw te installeren?

Ehmz...

Oorspronkelijk geplaatst door Blacky

Ik heb zelfs de hele squirrelmail weggehaald en middels ./build update en ./build squirrelmail weer opnieuw geinstalleerd, nog steeds hetzelfde probleem.

Ja dus... zelfde probleem.

Excuses, overheen gelezen.

Excuses is niet nodig hoor, ben al dankbaar dat je mee aan het denken bent.

Iemand nog een idee waarom Roundcube zonder problemen werkt en Squirrel zelfs na een herinstallatie van Squirrel niet?

Heb je dit probleem weten op te lossen uiteindelijk?

Nee, sterker nog, eergisteren een nieuwe server ingeregeld, DA erop, Squirrel erop, daarna mod_ruid en hups, weer hetzelfde probleem.
Dus die werkt nu ook noodgedwongen met Roundcube.

Hi
heb het zelf al even geleden uitgevogeld, en dacht toevallig aan dit topic. Hier is de oplossing:
Maak de custom config

Code:

cd /usr/local/directadmin/data/templates
cp virtual_host2.conf custom
cd custom
nano virtual_host2.conf

Dit moet in het bestandje staan:

Code:

|?DOCROOT=`HOME`/domains/`DOMAIN`/public_html|
|?OPEN_BASEDIR_PATH=`HOME`/:/tmp:/usr/local/lib/php/|
<VirtualHost |IP|:80>
|CUSTOM|
|?CGI=ScriptAlias /cgi-bin/ `DOCROOT`/cgi-bin/|
        ServerName www.|DOMAIN|
        ServerAlias www.|DOMAIN| |DOMAIN| |SERVER_ALIASES|
        ServerAdmin |ADMIN|
        DocumentRoot |DOCROOT|
        |CGI|

        |USECANONICALNAME|

        #SuexecUserGroup |USER| |GROUP|
        RMode config
        RUidGid |USER| |GROUP|
        RGroups apache
        CustomLog /var/log/httpd/domains/|DOMAIN|.bytes bytes
        CustomLog /var/log/httpd/domains/|DOMAIN|.log combined
        ErrorLog /var/log/httpd/domains/|DOMAIN|.error.log

        <Directory |DOCROOT|>
                Options +Includes -Indexes
                php_admin_flag engine |PHP|
                php_admin_flag safe_mode |SAFE_MODE|
                php_admin_value sendmail_path '/usr/sbin/sendmail -t -i -f |USER|@|DOMAIN|'
|*if OPEN_BASEDIR="ON"|
                php_admin_value open_basedir |OPEN_BASEDIR_PATH|
|*endif|
        </Directory>

        <Directory |DOCROOT|/cgi-bin>
                Options +ExecCGI
        </Directory>

|HANDLERS|
|MIMETYPES|

</VirtualHost>
<VirtualHost |IP|:80>
  ServerName webmail.|DOMAIN|
  ServerAdmin |ADMIN|
  RUidGid webapps webapps
  RGroups apache
  DocumentRoot /var/www/html/webmail
  CustomLog /var/log/httpd/domains/|DOMAIN|.bytes bytes
  CustomLog /var/log/httpd/domains/|DOMAIN|.log combined
  ErrorLog /var/log/httpd/domains/|DOMAIN|.error.log
</VirtualHost>

Het gaat om het laatste stuk, daarbij stel je in mod_ruid als de user webapps en daardoor heb je geen schrijfrecht fouten. Waar ik bij het instellen toen op vast liep, was dat webmail wilde chmodden en daarbij een foutmelding gaf. De oplossing is eenvoudig:

Code:

chmod 777 /var/www/html/webmail/tmp

Hierdoor is een chmod niet meer nodig.

Toelichting:
Je dient zelf een A record aan te maken voor de webmail die wijst naar de IP die ingesteld is bij de gebruiker.

Dit is voor de nieuwe gebruikers:

Code:

cd /usr/local/directadmin/data/templates
cp dns_a.conf custom
cd custom
echo "webmail=|IP|" >> dns_a.conf

Atmail verzend probleem
Als je die ook krijgt, doe dit

Code:

 echo 127.0.0.1 >> /etc/virtual/whitelist_hosts
/sbin/service exim restart

Alle clients zullen werken vanaf webmail.domein.tld/webmail


Hoop dat je er wat aan hebt, moest het even snel tikken (beetje rommelig denk ik). Als het niet lukt of als ik wat vergeten ben, tell me.

Edit: Je kan natuurlijk de aliassen weghalen zodat alles alleen vanaf webmail.domain.tld bereikbaar is, echter moet je /var/www/html/webmail in de virtualhost config aanpassen naar /var/www/html .

Bedankt voor de uitleg. Ik zal het eens op een van de servers proberen. Zelf ben ik echter niet zo'n liefhebber van extra 777 directory's.

Moet dat extra A record er perse bij? Want het is verder prima als de mensen het bereikt kunnen krijgen via http://hun.domein.nl/webmail zoals het nu ook het geval is met Roundcube.

Maar in elk geval fijn dat je er nog aan dacht en de uitleg hier!

Oorspronkelijk geplaatst door Blacky

Bedankt voor de uitleg. Ik zal het eens op een van de servers proberen. Zelf ben ik echter niet zo'n liefhebber van extra 777 directory's.

Moet dat extra A record er perse bij? Want het is verder prima als de mensen het bereikt kunnen krijgen via http://hun.domein.nl/webmail zoals het nu ook het geval is met Roundcube.

Maar in elk geval fijn dat je er nog aan dacht en de uitleg hier!

Je kan ook zonder webmail werken, had hier de voorkeur voor. Echter draai je op webmail.domein.tld wel als de gebruiker webapps. Echter smarty probeert de dir tmp te chmodden naar 777 (vraag me niet waarom, misschien dat je dit ergens kan uitschakelen in smarty) en loopt daarop vast.

Edit: zonder webmail.domein.tld kan niet, sorry foutje. Ik krijg iedere keer weer fouten, als iemand een betere oplossing heeft dan hoor ik dat graag.

Oke prima dus het is te fixen maar dan moet het wel via de webmail.domein.tld in plaats van via www.domein.tld/webmail.
Geen probleem, men kan in elk geval dan wel Squirrel draaien en webmail.domein.tld staat ook wel mooi, toch?
Thanks!

Oorspronkelijk geplaatst door Blacky

Oke prima dus het is te fixen maar dan moet het wel via de webmail.domein.tld in plaats van via www.domein.tld/webmail.
Geen probleem, men kan in elk geval dan wel Squirrel draaien en webmail.domein.tld staat ook wel mooi, toch?
Thanks!

Persoonlijk vind ik het niet zo'n probleem. En anders verwijder je de webapps en maak je op een eigen server de webmail aan. Zat vandaag hieraan te werken: webmail.yourwebhoster.eu . Ik heb de code hier een beetje aangepast waardoor op de door mij ingestelde servers ingelogd kan worden (niet de traditionele manier van uebimiau). Dan zou ik niet iedere keer alles hoeven in te stellen op de webservers en draait alles centraal. Maar goed, dit is natuurlijk een optie waar je rekening mee kan houden en ik weet niet in hoeverre de andere e-mail clients hier ondersteuning voor hebben en wat je hiervoor moet aanpassen. Misschien als het weer eens slecht weer is.

Ik vind het zelf ook niet zo'n probleem.
Dat van de webmail doen op een eigen server is misschien ook wel een aardig idee, maarja daar heeft eigenaar misschien geen zin in, die houdt de zaken nogal graag standaard, hoeft ie zelf niet te zoeken.
Maar toch leuk om misschien eens te proberen met wat slechter weer inderdaad of van de winter.

Even een kickje: Tim heeft een andere oplossing bedacht, zie http://www.webhostingtalk.nl/directa...ml#post1141014