Re: OpenPKG environment question
On Thu, Aug 05, 2004, Alexander Belck wrote: I don't know exactly what is needed for the openpkg_binaryies. I set up the sugested opa() function and after login I issue opa /opkg. That works nice, but if I need to execute a bin without login ? Is it fine to give the full path for the openpkg binary without prior preparing the environment (without opa /opkg) ? Sure, just run the foo program via /opkg/bin/foo. Also, is there any proplem using one server from the underlaying OS that integrat with services run from OpenPKG at the same hoste ? [...] Yes, if you have for instance Postfix MTA installed both from the vendor and from OpenPKG is will conflict at least when trying to bind to the listening socket. Either disable the vendor daemon or even deinstall it. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: FreeRadius
On Thu, Aug 05, 2004, Alexander Belck wrote: Is there any plan to include FreeRadius in OpenPKG ? [...] We have a freeradius package in OpenPKG-CURRENT since 2 weeks. It is a little bit weak in build-time portability and not still well tested by us under run-time, but try it out and feel free to give us feedback. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: FreeRadius
On Thu, Aug 05, 2004, [EMAIL PROTECTED] wrote: Whats needed to put freeradius under ftp.openpkg.org/release/2.1/SRC/PLUS/ ? Well, there _is_ a freeradius package, but only in ftp://ftp.openpkg.org/current/SRC/ because it is still not part of any release... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: OpenPKG bind in chroot ?
On Thu, Aug 05, 2004, Alexander Belck wrote: 1st) Is OpenPKG ver of bind chroot enabled (-t chrootdir) ? No, not out of the box. If you really want this you have to establish your own chroot(2) environment under /foo for BIND and use bind_flags=... -t /foo ... in rc.conf. 2nd) opkg_bind uses opkg[-r] user. Does I gain more security using an distinct user and chrooting opkg_bind ? Well, theoretically yes, practically no IMHO. This everyone has to decide on his own. Security is always a compromise between not doing anything and allowing everything. I personally think OpenPKG's default of using the dedicated restricted user is reasonably secure here. 3rd) What does option with_dlz enables ? It's for serving both zone and meta informations directly out of a RDBMs like MySQL or PostgreSQL. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl
On Thu, Aug 05, 2004, Bill Campbell wrote: On Thu, Aug 05, 2004, Alexander Belck wrote: Some perl scripts use #!/usr/bin/perl I recommend you replace that with /opkg/bin/perl. Could I just symlink ln -s /opkg/bin/perl /usr/bin/ ? I do not recommend replacing such a critical part of the OS with OpenPKG stuff. You must assume strange side effects. Last week I had to fix an application of mine which worked well with perl-5.8.3 but ran into a infinite loop with perl-5.8.4. It was neither a bug in the app nor in perl. It was just a subtle little intentional change in perls behavior where my code expected something else. Now imagine how badly you break many of you vendors maintenance scripts by replacing an ancient perl with the latest and greatest version. Do not even try. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Perl
I thought that being able to use the most up to date version of perl should avoid bug or security problems corrected in newer versions (while correct scripts should further run as the language syntax and standarts should not change). Yes, but it can also break existing scripts that depend on older versions of perl. You're far better off to leave the original perl alone, letting existing scripts use the version they expect. New things like ISPman can be built under the OpenPKG system where they will use the most current versions built in a consistent environment (not of of Red Hat's strong suits :-). So how should I make ISPman use the OpenPKG perl ? ISPman has about 100 perl scripts, constantly updating over cvs, and all start with: #!/usr/bin/perl Can you suggest me what to do ? Also, Ralf Engelschall replied to my environment saying thats OK just to run a OpenPKG binary giving the full path, so coult I just use #!/opkg/bin/perl ? I realy don't understant what is all done by /opkg/etc/rc --eval all env. I see that the PATH, LD_LIBRARY_PATH, MANPATH and INFOPATH are prepend with /opkg_paths, but don't know if other things are changed. Thanks again, Alex-- ATIX Tecnologia e Com Ltda Tel.: +55-(11) 4667-5900 This message was sent using IMP, the Internet Messaging Program. __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
