On Fri, Sep 01, 2006 at 11:05:43AM -0700, Doug Barton wrote: > Brooks Davis wrote: > > On Thu, Aug 31, 2006 at 10:33:45PM -0700, Doug Barton wrote: > >> Jiawei Ye wrote: > >> > >>> I can see that postgresql requires LOGIN, but jabberd is BEFORE:LOGIN, > >>> what is the proper solution? > >> If I understand correctly, pgsql runs as an unprivileged user, which means > >> it needs to REQUIRE LOGIN. OTOH, there is no reason that jabberd should run > >> BEFORE LOGIN, and I suspect that is an artifact of copying and pasting a > >> script that had that in it for no good reason. In fact, > >> ports/net-im/jabber/files/jabberd.sh.in does not have that line, so I am > >> wondering what port you're working with here. > > > > I'd agree that pgsql should REQUIRE LOGIN, but I think the reason is > > subtilly different. In my mind the key with LOGIN is that the system > > is ready security wise to allow users to interact with the machine via > > methods other than the administrative console. This should mean the > > secure level is elevated and any other security bootstrapping is done. > > IIRC this is actually not the case and should be fixed. > > That's an interesting idea, I'll have to give it some more thought.
This is what LOGIN has to say for it self: # This is a dummy dependency to ensure user services such as xdm, # inetd, cron and kerberos are started after everything else, in case # the administrator has increased the system security level and # wants to delay user logins until the system is (almost) fully # operational. > >> In any case, the proper fix here seems to be to have jabber REQUIRE > >> postgresql. Try that, and if it works, you're golden. > > > > There are a couple problems with "REQUIRE postgresql" in general: > > I wasn't speaking in general. :) I probably should have > s/here/in your situation/ to make it more clear what I meant. I suspected that was the case, but wanted to insure this didn't get committed. > > I think the right thing is create a stub DATABASE provider that mysql > > and postgres can be BEFORE. Ports that want a database can just depend > > on that. It will insure that ordering is correct if the server is local > > without causing problems if it isn't or requiring script modifications > > for ports that can use more than one database from the same package. > > No objections on my side, but I am not in a position to develop or test it, > since I'm not using any database stuff at the moment and don't have any > spare cycles. This topic came up on the -rc list a while back and no one bit > the apple, so if there is a user (or committer) here who wants to work this > one out, please feel free to take this project up, and report your findings > on [EMAIL PROTECTED] The big question in my mind is, do we make a port to do this or add it to the base? I think we'd need a port for compatability so we might just want to create one and always use it. -- Brooks
pgpTJ1YB2GXCj.pgp
Description: PGP signature