Ok here is some facts: When apache is started, and Rivet gets loaded, it calls the RivetInitChildScript.
In this script, I init all DB connections, open some TCP sockets, and generate a log file under /tmp. This is working. and a log file is created under the /tmp/xxxxxxxj/tmp/mylog and no error is thrown. Now in a vhost rivet's page, I also open the same log file than in the RivetInitChildScript but this time this fails with an access denied. Seems like when I am in a rivet page, I am still in a jail environment which in that case I should, but for some reason the /tmp from an open file TCL command is not chroot to the jail location. Odd no ? On Mon, Feb 29, 2016 at 12:55 PM, Brice Hamon <[email protected]> wrote: > YES ! Massimo, you're my man ! > > You are correct. > > There are these directory created with Apache for each session: > > drwx------ 1 root root 6 Feb 29 11:48 > systemd-private-12df8e01068042e5ad05fd1d2f53d105-apache2.service-x1ju4j/ > drwx------ 1 root root 6 Feb 12 12:40 > systemd-private-aabb5b21c29e443e818503e8cf083632-apache2.service-ijtQVT/ > > And inside I see some startup log file created in the RivetChildInit > script. But in rvt page, I am opening also a log file in /tmp and it fails > of course. > > I will have to find a way to know where my /tmp is from inside rivet, or > forcing OpenSuse to run Apache "normally" ? > > Thanks again Massimo :) > > On Mon, Feb 29, 2016 at 11:58 AM, Massimo Manghi <[email protected]> > wrote: > >> Hi Brice >> >> So if I understand correctly OpenSUSE is most likely where the culprit >> has to be found. If on it applications run in a jailed environment each of >> them should have its own /tmp space. I'm conjecturing but it's important >> for Rivet because by default the UploadDir for mime messages is /tmp and >> probably it wouldn't work in such environment. If you will get around the >> problem the analysis could be important in order to have Rivet fit well is >> these systems. Let me know >> >> >> -- Massimo >> >> On 02/29/2016 05:47 PM, Brice Hamon wrote: >> >>> Quick update, >>> >>> I ruled out Rivet, as the 2.2.3 version working fine with Apache 2.2 >>> does not work for me with Apache 2.4. >>> >>> On Mon, Feb 29, 2016 at 9:30 AM, Brice Hamon <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Thanks guys, >>> >>> I am going to downgrade rivet running in prod to rule out Rivet. >>> >>> Maybe it is a Apache config issue. Can you send me a Apache 2.4 >>> mininal vhost config that works for you? >>> >>> Thanks, >>> >>> Brice. >>> >>> On Mon, Feb 29, 2016 at 4:44 AM, Harald Oehlmann >>> <[email protected] <mailto:[email protected]>> >>> >>> wrote: >>> >>> Hi Massimo, >>> >>> I will make the connection by private mail. >>> >>> Best regards, >>> Harald >>> >>> Am 29.02.2016 um 10:40 schrieb Massimo Manghi: >>> > Hi Brice >>> > >>> > I'm afraid the guys at OpenSuse would have better luck >>> helping you. >>> > Reinhard Max works for SUSE (http://wiki.tcl.tk/1003) if the >>> wiki page >>> > about him is accurate as to his employer. Harald has a good >>> personal >>> > connection to Reinhard and he may introduce you to him >>> > >>> > -- Massimo >>> > >>> > On 02/26/2016 04:23 PM, Brice Hamon wrote: >>> >> Hi all, >>> >> >>> >> Still no luck. >>> >> >>> >> I did a fresh install of OpenSuse 13.2, install the Rivet >>> 2.2.4 and >>> >> recompiled it with simple options: >>> >> >>> >> ./configure --with-apxs=/usr/bin/apxs2 --prefix=/usr/local >>> >> >>> >> Rivet works fine, just I can't create files locally. >>> >> >>> >> [Fri Feb 26 10:07:28.021057 2016] [mpm_prefork:notice] [pid >>> 5085] >>> >> AH00163: Apache/2.4.10 (Linux/SUSE) OpenSSL/1.0.1k-fips >>> Rivet configured >>> >> -- resuming normal operations >>> >> [Fri Feb 26 10:07:28.021230 2016] [core:notice] [pid 5085] >>> AH00094: >>> >> Command line: '/usr/sbin/httpd2-prefork -f >>> /etc/apache2/httpd.conf -D >>> >> SSL -D SYSTEMD -D FOREGROUND' >>> >> [Fri Feb 26 10:08:33.768082 2016] [:error] [pid 5105] >>> login.rvt: error: >>> >> BH: couldn't open "/tmp/log_ydotm": permission denied >>> >> >>> >> I used NIS, so I removed that machine from it, this machine >>> is now >>> >> standalone. >>> >> >>> >> AppArmor is disabled. >>> >> >>> >> Any ideas? I am out of ideas. >>> >> >>> >> Thank guys, >>> >> Brice. >>> >> >>> >> >>> >> >>> >> >>> >> On Fri, Feb 12, 2016 at 10:48 AM, Massimo Manghi >>> >> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>> wrote: >>> >> >>> >> On 12-02-2016 16:41, Brice Hamon wrote: >>> >> >>> >> Thanks guys, >>> >> >>> >> I am running Apache 2.4.10. >>> >> >>> >> Good idea Harald, I did not think about it. I will >>> check and >>> >> report. >>> >> >>> >> Thanks. >>> >> >>> >> >>> >> In fact Harald's clue is a very good one. I didn't know >>> of this >>> >> mobile oriented approach adopted by for these systems >>> >> >>> >> -- Massimo >>> >> >>> >> >>> > >>> >>> >>> -- >>> ELMICRON Dr. Harald Oehlmann GmbH >>> Koesener Str. 85 >>> 06618 Naumburg >>> Germany >>> Phone: +49 (0)3445 78112-0 <tel:%2B49%20%280%293445%2078112-0> >>> Fax: +49 (0)3445 78112-19 <tel:%2B49%20%280%293445%2078112-19> >>> www.Elmicron.de <http://www.Elmicron.de> >>> German legal references: >>> Geschaeftsfuehrer: Dr. Harald Oehlmann, Jens Oehlmann >>> UST Nr. / VAT ID No.: DE206105272 >>> HRB 212803 Stendal >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> <mailto:[email protected]> >>> For additional commands, e-mail: [email protected] >>> <mailto:[email protected]> >>> >>> >>> >>> >> -- >> -- >> Dipartimento di Neuroscienze >> Unità Biofisica e Fisica Sanitaria >> via Volturno 39 >> 43125 Parma >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
