Onderwerp: File rechten bewaren met mod_ruid?

Ben met Osticket aan het stoeien geweest en we zitten op een DA server met mod_ruid2 en maken gebruik van email piping.
Wat is nu aan de hand? Elke keer als Osticket geupdate wordt, dan wordt de /api/pipe.php weer op 644 gezet omdat hij vervangen wordt vermoedelijk en dan werkt deze niet meer.
Dan moeten we hem dus handmatig weer naar 755 gaan zetten.

Is er ook een mogelijkheid om dit bestand op 755 te houden, maar dan wel zo dat hij wel geupdate (dus overschreven) kan worden?
Of kan men beter een andere wijze dan piping gebruiken met Osticket, en zoja waarom?

waarom doe je aan piping?
Hoe update je en welke versie gebruik je? Als je 1.8 pakt dan is er al een update GIT script, als het om 1 file gaat zou je die ook CLI kunnen chmodden naar 644 toch?

waarom doe je aan piping?

Daarom vroeg ik ook of er misschien een betere methode was. Ik gebruik piping om een notificatie te krijgen op mijn email adres dat er een nieuw ticket is binnen gekomen maar vooral ook om een kopie te krijgen van de vraag van de klant. Wel handig zo'n automatische kopie naar mezelf, zeker als de pipe niet lekker werkt. Als er iets beters is hoor ik het uiteraard graag.

De versie die nu geinstalleerd staat is geinstalleerd door en wordt geupdate door installatron (pas geupdate naar 1.8). Gewoon omdat dit lekker werkt, ook de laatste nieuwe versies heeft en automatisch zowel doet backuppen alsook minor versions updaten.
Het gaat alleen om die pipe.php en die staat staat normaliter al 644 maar moet dus 755 zijn anders krijg ik volgende foutmelding:

T=virtual_address_pipe: Child process of virtual_address_pipe transport returned 127 (could mean unable to exec or command does not exist) from command: /home/blacky/domains/mijndomein.nl/public_html/support/api/pipe.php

Wat is het verschil tussen gewoon chmod en CLI chmod? Of is dat hetzelfde?

Ik doe "gewoon" POP of IMAP,
Wat doe jij precies met piping? update: bij ons komt er een team notification. Beetje spammy maar dan hebben meerdere mensen tegelijk een melding.

Wij trekken de mail leeg, geen copietjes achterlaten, ook gezien dat formulieren zelf al hun data opslaan.

Ik ben ZZP'er dus bij mij hoeft het niet naar een heel team. Wat ik met piping doe heb ik net boven uitgelegd.

Ik gebruik piping om de mail die de klant stuurt, in de Osticket database te krijgen. Dit vanwege het feit dat ik ook met m'n email client gewoon de mail ophaal en daarmee ook leeg trek, laat ook geen copietjes achter.
Als je pop/imap gebruikt gaat het systeem zelf pollen. Dan zou ik het ophalen van dat mail adres in mijn client moeten uitschakelen, danwel aangeven dat hij de mail op de server achter moet laten voor x tijd.
Gaat er dan iets mis met osticket, krijg ik helemaal niets binnen op m'n support adres. Met piping heb ik dat probleem niet, vandaar piping.

Ok, dus je wil tickets maken EN achteraf nog via een mail client uitlezen?

Dat kan prima met POP en IMAP en dan aanvinken move to folder. Dan gooit ie m niet weg maar ziet ie m wel als processed.

Ja dat klopt, maar dan moet ik ook een cron maken enzo. Met pipe hoef ik nergens meer naar te kijken, werkt perfekt.
Behalve dus dat ik effe moet zorgen dat die pipe.php op 755 blijft staan.

standaard forwarder naar jezelf instellen wellicht een optie?

Ja is ook een optie inderdaad. Maar ik vind het toch vreemd dat bij overschrijven van een file, de attributen gewijzigd worden. Ik had van Linux toch echt gedacht dat die daar wel een middeltje tegen zou hebben.

Als je het "sticky bit" zet op het bestand dan wordt het niet geupdate. (Wel even file ownership controleren) Enige nadeel is dat als pipe.php wordt geupdate dat je dat handmatig moet doen...

Ja de sticky bit had ik al gevonden, maar net zoals je zegt... dan wordt het niet geupdate als er een update voor is.
Ik dacht dat er misschien ook nog een ander soort "preserve attribute" was waarbij het bestand wel overschreven kon worden maar dat is er dus niet.

In elk geval mogelijkheden genoeg. Zal nog eens kijken naar email polling (pop/imap) en anders wordt het vermoedelijk toch die sticky bit want aan die pipe.php zal toch niet snel iets noemenswaardigs veranderen.

Dank allemaal voor het meedenken!

Dat ie op 644 komt te staan is logisch met een standaard umask van 022 en voor mod_ruid2 is 644 ook ruim voldoende.
Eigenlijk geef je met 755 iedereen rechten om de pipe aan te trappen, vraag is of je dat moet willen, maar een cronjob die elke minuut gewoon een
chmod 755 home/blacky/domains/mijndomein.nl/public_html/support/api/pipe.php
doet lijkt met makkelijkste oplossing. Kost vrijwel geen resources tenslotte en je kunt updaten wanneer je zin hebt zonder ergens naar om te kijken of ingewikkelde truukjes uit te halen.

Die pipe support alleen local piping dus dat maakt niet zoveel uit. Vind het wel jammer dat osticket hem niet gewoon met 644 kan gebruiken.
Ik denk echter niet dat het met een cronjob kan werken. De pipe wordt namelijk aangeroepen doordat je een forward maakt van een email adres:

Code:

<EMAIL>@domain to |/home/<USERNAME>/public_html/osticket/api/pipe.php

Wat ik wel zie is dat je normaliter ook de virtual_adres_pipe in Exim zou moeten aanpassen. En hierin verschilt alleen de "group =" in de exim.conf want die staat nu op nobody, en die zou dan eenzelfde regel moeten bevatten als "user =". Dan zou volgens mij het 755 probleem misschien ook over zijn.
Ik ben echter bang als ik dit ga wijzigen dat de gewone php mail() die door bijv. scripts als forums wordt gebruikt, niet meer zal werken of met de forwarders.

Misschien is dan email polling toch een betere optie om te gebruiken.

Natuurlijk kun je met een cronjob de rechten van de pipe.php op 755 zetten. Dat staat los van hoe de pipe wordt aangeroepen.

Oeps, sorry, ik had verkeerd gelezen, ik had de chmod in eerste instantie niet gezien en dacht dat je de pipe aanriep vanuit een cronjob.
Ja uiteraard kun je hem via een chmod laten wijzingen naar 755. Goed idee!