Squirrelmail werkt niet meer na upgrade software

[Verwijderd]

Ik had een werkende installatie van Squirrelmail op een Debian Sarge installatie. Na een upgrade van wat custom software kunnen gebruikers niet meer inloggen.

Natuurlijk denk je per direct dat er is iets veranderd is in een configfile, maar dit blijkt toch wat complexer te zijn.

Ik ben begonnen met het analyseren van de config.php van squirrelmail,maar deze bleek echt niet gewijzgd te zijn. Hier na ben ik gaan telnetten naar de IMAP-server en dit gaat perfect en zonder problemen, ik kan de INBOX openen en uitloggen, perfect dus.

OK, dus dan maar kijken of je remote via Outlook kun IMAP-PEN, geen probleem, werkt ook perfect.

Uiteindelijk Squirrelmail maar geheel verwijderen, de apt-get cache legen en opnieuw beginnen. Hierna krijg ik een error dat Squirrelmail niet in de /var/lib/squirrelmail/data map kan schrijven en dit kan pas nadat ik er 0777 aan toe ken. Dit is hetzelfde verhaal met de /var/spool/squirrelmail/attach map, maar met een 0777 chmod werkt dit uiteraard ook (hoe kan het ook anders).

Nog steeds kan ik niet inloggen. De IMAP-logs laten zien wanneer ik in wil loggen via Squirrelmail op de IMAP-server dat er direct weer uitgelogd wordt. Op Squirrelmail zijn verschillende FAQ's te vinden, maar na een hele dag zoeken stel ik de vraag hier ook maar.

Wat zijn nog mogelijkheden om te bekijken volgens jullie ?

Ik gebruik:

Debian Sarge
Postfix als MTA
Courier-IMAP
Squirrelmail
Apache2

Ik heb dus alle logfiles bekeken en vergeleken met backups en zodien terug gezet om te testen zonder resultaat.

Wat me wel opviel, maar dt is eerder al eens veranderd is dat squirrelmail nu als root:root geinstalleerd is en voorheen als squirrelmail:squirrelmail_grp. Na upgrades was het voorheen dus een keer root en na opvolgende upgrades weer squirrel als gebruiker.

Ik snap ik er even niets meer van.

Ik moet nog even proberen vanaf een andere Squirrelbak proberen te connecten maar dan moet ik even een testinstallatie opzetten.

[Verwijderd]

Move PNS > NOS

[Verwijderd]

Ik heb het nog iet op kunnen lossen, de situatie is nog steeds hetzelfde

[Blaasvis]

paar vragen

a) hoe heb je squirrelmail verwijderd ? --purge ?
b) waarom 777 ? en niet gewoon de map aanmaken en zorgen dat de juist user de recht krijgt ?
c) gebruik je testing/unstable ?

Ik heb zelf een soort gelijk probleem gehad op archlinux.
Hier moest ik de map aanmaken met mkdir -p
en de user nobody er aan toe wijzen.

[Verwijderd]

Blaasvis schreef op zaterdag 03 december 2005 @ 14:08:
paar vragen

a) hoe heb je squirrelmail verwijderd ? --purge ?

Beide geprobeerd, beide hetzelfde probleem

b) waarom 777 ? en niet gewoon de map aanmaken en zorgen dat de juist user de recht krijgt ?

Omdat de user met rechten helaas niet werkt Ik heb bij het zoeken gezien dat zelf Skinmakers als Nutsmail soms 777 adviseren

c) gebruik je testing/unstable ?

Eerst stable en daarna unstable. Unstable had ik nodig voor een plugin die anders niet werkt. Unstable werkte goed, nu werken beide niet meer. De configtest van squirrel keurt alles goed.

Ik heb zelf een soort gelijk probleem gehad op archlinux.
Hier moest ik de map aanmaken met mkdir -p
en de user nobody er aan toe wijzen.

Er is op de squirrelmail mailinglist ook iemand die een dergelijk probleem heeft met testing, helaas niemand die daar een goed antwoord op heeft... het zou in zijn geval aan PHP moeten liggen maar dat betwijfel ik.

[Arnout]

Ben je naar PHP 5 over gegaan?

[Verwijderd]

Arnout schreef op zondag 04 december 2005 @ 00:18:
Ben je naar PHP 5 over gegaan?

Nope, 4.3.10-16 is wat ik draai. Het zou een probleem met de sessies moeten zijn, maar niets in de php.ini lijkt gewijzigd. Ik ben druk met sessies aan het testen, kom alleen niet echt verder.

[Verwijderd]

Ik denk er over om PHP4 opnieuw te installeren. er gaat iets mis met die Sessies volgens mij, maar nu na dagen testen... zou bijna van scratch willen beginnen

[arikkert]

777 is nogal bot. Kan ook zijn dat sommige programma's niet willen werken met directories waar ze afhankelijk van zijn en die zulke access-modes hebben.

Chown (-R) de directories waar de webuser controle op heeft, naar de webuser. Kijk in de apache.conf of httpd.conf van apache2 welke dat is, meestal iets als www of nobody.

[ Voor 12% gewijzigd door arikkert op 04-12-2005 17:25 . Reden: typos ]

[Verwijderd]

Check even goed in de buglist van Squirrelmail.
Ik ben recentelijk overgestapt naar PHP 5.0.5 en Squirrelmail werkt sindsdien niet.
Blijkt bugje in Squirrelmail te zijn, dan maar tijdje zonder webmail.
Misschien heeft jou probleem hier ook iets mee te maken.
Doe ff een google op eventuele foutmeldingen die je krijgt, dan wordt je vast snel wijzer.

PS Ben ook over op MySql 5.0, erg leuk maar je loopt weer tegen enorme problemen aan icm andere software. Zo kan ik met phpmyadmin de privileges niet meer aanpassen..
Nog niet naar kunnen kijken, maar ook dat komt wel weer goed.


Als je op safe wil spelen moet je niet de meest recente sources compilen, dan is er altijd wel iemand die eerder tegen het zelfde probleem is aangelopen.

[Verwijderd]

Bedankt voor je info ! Ik ben al dagen aan het zoeken geweest en nog niet de juiste informatie kunnen vinden. De sources zijn nog steeds hetzelfde als ze waren... werkte dus wel.

Webmail is handig

[stekkel]

Heeft de apache user write access in de session dir?

Kan je controleren of er in die directory uberhaupt session files staan en wat is de inhoud er van?

Heb je al geprobeerd om alle plugins te disablen?

Weet je dat alleen de CVS versies van SquirrelMail met php 5.0.5 werken?

[Verwijderd]

stekkel schreef op dinsdag 06 december 2005 @ 14:01:
Heeft de apache user write access in de session dir?

Kan je controleren of er in die directory uberhaupt session files staan en wat is de inhoud er van?

Heb je al geprobeerd om alle plugins te disablen?

Weet je dat alleen de CVS versies van SquirrelMail met php 5.0.5 werken?

Allemaal bekend en werkend. Ik draai nu een 1.4.5 dus geen CVS en ik gebruik PHP4 dus dat zit wel ok.

Er is geen plugin enabled at the moment.