Re: Openpkg portability
On Friday, 26. October 2007 at 11:40 pm, J P wrote: once the installation is setup everything appears to be hard-coded to that directory structure. [...] playing with the openpkg installation script openpkg-20071019-20071019.sparc64-solaris9-openpkg.sh it appears that the USERNAME, GROUP, and PREFIX PATH that was used to compile the script is hardcoded in 100's of places in the file [...] This observation is correct. I want to emphasize that this behavior is not limited to the bootstrap but is also true for a lot (albeit, at least in theory, not all) of the packages. This works as designed. Too many applications suck information from their build environment into their binaries. OpenPKG assumes that it is not possible to create packages which are truly independent from their prefix, user and group names and ids. You may feel there are a lot of packages where the goals relocation and user/group name/id independence could be achieved but there are too many where these goals are unreachable. It is often even hard to create packages which are build in an area different from their final installation path, but this goal is mandatory for OpenPKG and some packages must be already tweaked a lot to achieve even this goal. My question is that once we create a unique installation script for each set of servers will we be able to safely reuse the same binary RPM files that were originally created under the /export/home/tambu/openpkg directory? Or do we have to recompile everything including all the perl modules? You can build binaries from sources for arbitrary prefix, user and group names and ids. You specify these parameters when building the bootstrap from source. As you already found out, they will be hardcoded into the bootstrap binary. All packages you build from source using this bootstrap will inherit these parameters and also have them hardcoded. The simple rule is: build binaries from source for every prefix, user and group names and ids combination. Then deploy these binaries to one or more machines which use exactly the same combination. If you want to see the available options which can be passed to the bootstrap build process or even want to pull the actual values from an existing bootstrap, please review my cloning OpenPKG: bootstrap [1] article. [1] http://www.lotterer.net/blog/en/41 -- http://thomas.lotterer.net __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: gmp-4.2.1 compile problems
On Tuesday, 3. July 2007 at 10:19 pm, Ralf S. Engelschall wrote: Can it be that this is a 32-bit Linux distribution *user-land* running with a 64-bit Linux *kernel* on a 64-bit *hardware*? We did some research on this topic recently. I published our findings now. OpenPKG: 32bit vs. 64bit Lessons learned from attempting to create a pure 64bit OpenPKG instance on a system made from mixed 32bit/64bit parts. OpenPKG builds and runs fine in any pure environment where parts are either all 32bit or all 64bit. Problems and limitations arise from any attempt to mix 32/64 ... http://www.lotterer.net/blog/en/78 -- http://thomas.lotterer.net __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: run control behavior
On Monday, 11. June 2007 at 6:26 pm, Dan Cox[EMAIL PROTECTED] wrote: A few peculiarities with the OpenPKG run control system are causing some end user confusion when working with services. (Using openpkg-20070608) [...] Thoughts/comments? Thanks a lot for the detailed report, Dan. All of what you reported describes correctly what openpkg rc is doing today. I traced down that much of the difference between your expectations and actual behavior seems to come from a different definition of disabled. For openpkg rc, disabled means not do the action. It seems to me your definition can be described as not run the daemon. So we end up with OpenPKG disabled: openpkg rc start foo - not do the start openpkg rc status foo - not do the status openpkg rc stop foo - not do the stop Dan disabled: openpkg rc start foo - not run the daemon, refuse start openpkg rc status foo - not run the daemon, display status anyway openpkg rc stop foo - not run the daemon, stop if it running anyway The stop anyway case happens likely if disabling the daemon after start. It seems to me both approaches are valid. The Dan approach is just not implemented. Worse for OpenPKG, the Dan approach seems to be natural for humans. I have to investigate whether it is possible to implement your approach, too. We need to find a good name for both in order not to confuse users too much, considering rc_all and rc_def, too. Maybe renaming the existing functionality to dormant does the job. -- -- http://thomas.lotterer.net __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Problems configuring postfix to forward to syslog
Wilson Jason[EMAIL PROTECTED] wrote on 2007-03-01 04:26: This I have done and worked out the order of the parameters is important. Using 'syslog(target=remote)' fails, but 'syslog(remotehost=localhost,target=remote)' works. The remotehost parameter needs to be specified before you specify that the target is remote. Suggest that the documentation is clarified and the examples updated. Thanks for working out. I have to dig into the l2 code to find out the root cause of this issue but I believe the problem comes from sanity checking, something like: if remote then check whether host has been set. Not intuitive from a user's perspective. -- http://thomas.lotterer.net __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: openpkg build -r not work with local fs mirror
Doug Henry [EMAIL PROTECTED] wrote on 2007-02-28 20:23: I take it relative paths are no longer supported? Previously I had the line -r . in my ~/.openpkg/build file. I don't wanna say relative paths are supported because the openpkg setUID wrapper may change directory under certain circumstances. One case I know of is that it changes to $HOME when $PWD becomes inaccessible, which can happen if an instance manager has the current working directory on a NFS drive with the usual root-nobody mapping and executes a command which requires root privileges. That said I also do not want to introduce artificial limitations. So I added support for relative paths identified by ./ (no plans to add .. or all but leading / detection). Available with openpkg-tools-1.4.4, included with openpkg-20070302. -- http://thomas.lotterer.net __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: Problems configuring postfix to forward to syslog
Wilson Jason[EMAIL PROTECTED] wrote on 2007-02-28 02:00: Could someone please help me with configuring postfix to sends its logs to both a local file and to a syslog server? For debugging aid please have a look at the last paragraph of http://marc.theaimsgroup.com/?l=openpkg-devm=116608524305991 On a related question - does the fsl library re-read configuration on the fly - or it only on startup? The fsl reads all fsl.* files from it's configuration directory on every openlog() call from the application. A common pitfall is to store defective, testing and copies of fsl.* files in the directory which confuses fsl because it reads them all and concatenates them into a huge string. This also leads to the problem of one defective file - independent of the application - affects all fsl applications. The root cause of these problems is the fact that fsl is a library being built before the application. It really doesn't know anything about the application that is using it. Because fsl replaces the existing syslog API, extensions are not possible. The only way fsl knows about it's host is through the information that is passed through the openlog() call - which is optional by definition of the syslog API. At that time, the config must have been read with zero knowledge. -- http://thomas.lotterer.net __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: openpkg build -r not work with local fs mirror
Ralf S. Engelschall[EMAIL PROTECTED] wrote on 2007-02-23 11:04: On Fri, Feb 23, 2007, Victor G. Bolshakov wrote: As i understand, openpkg-tools not work with local fs mirror from OpenPKG 2.20070221: Sure, it is. Just specify -r file:///path instead of -r /path on the openpkg build command line until Thomas adds a wordaround which does this automatically. I changed openpkg tools today [1] in the hope to create a behavior which is compatible and intuitive. It is now possible to use a URL or an absolute path pointing to a package repository. Using URL style, including file://, engages openpkg curl to download a local copy of the package before use while using an absolute path, beginning with /, direct access is used. $ openpkg build -r ftp://download.example.com/repo foo $ openpkg build -r http://download.example.com/repo foo $ openpkg build -r https://download.example.com/repo foo $ openpkg build -r file://download.example.com/repo foo ... openpkg curl -o foo.src.rpm ...//download.example.com/repo/foo.src.rpm openpkg rpm --rebuild foo.src.rpm openpkg rpm -Uvh foo.rpm rm foo.src.rpm # unless -k (keep) option specified or $ openpkg build -r /mirror/repo foo ... openpkg rpm --rebuild /mirror/foo.src.rpm openpkg rpm -Uvh foo.rpm I hope that makes sense to everyone. [1] http://cvs.openpkg.org/chngview?cn=34214 - openpkg-tools-1.4.2 - openpkg-20070226 -- http://thomas.lotterer.net __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: [solaris] apache, php, imap
Luka, luka6000[EMAIL PROTECTED] wrote on 2006-12-13 16:28: I'm having problems trying to build kolab on solaris 10, openpkg 2.20061018 as of today it is not a good idea to use kolab from the OpenPKG repository. The Kolab project is using OpenPKG but they needed some adjustments to make their solution work, diverging from the original. Tomorrow the last attempt to resynchronize and import the diverged code back into OpenPKG celebrates it's second anniversary - in Internet time frames it means the OpenPKG kolab package is ancient :-) The good news is that (independent of your inquiry, really) I talked to Kolab project management yesterday and chances are we get back on track before the next snapshot mid February 2007. Until work starts on that endeavor it's best to download the latest Kolab packages from Kolab, not from OpenPKG. I've found that the bug with conflicting types for 'utf8_mime2text' is already resolved for php 5.2.0 and this version is included in openpkg tree [...] php package and it is 5.1.6 which from obvious reasons will not work. I investigated and found out the problem you are talking exists with apache-1.3.37-2.20061018 and has been fixed in 2-STABLE [1] with apache-1.3.37-2.20061103. The same package was recently copied as update into 2-STABLE-20061018 [2]. So this problem should be fixed now. I know that the problem is rather with imap then php, but why is php package included in apache and not using php package from tree? I do not know all the details but it is my understanding that in order to build mod_php using static code for both the source trees of Apache and PHP need to be mixed or at least they must be available simultaneously. Entwined building, that means unpacking two packages at the same time to mix them together, is not a feature of RPM. Fortunately such a situation does not happen often so for the rare cases embedding is a viable solution. And BTW there is an option to build Apache w/o PHP and let it run the external PHP for every request. Which is a clean solution but also a performance killer. [1] 2-STABLE CVS branch creates package files for ftp://ftp.openpkg.org/stable/2 [2] 2-STABLE-20061018 Snapshot creates package files for ftp://ftp.openpkg.org/stable/2.20061018 -- Thomas __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: gcc 32/64
Doug Henry[EMAIL PROTECTED] wrote on 2006-11-30 14:24: I am trying to compile openpkg stable 1018 snapshot on a 64-bit machine. Once the 32-bit stuff starts building I get the attached error. Sounds to me like the problems which were fixed in the following checkins. In short terms OpenPKG supports both 32bit and 64bit but only one or the other and not both simultaneously. http://cvs.openpkg.org/chngview?cn=32637 do not use multilibs (32+64bit) but stick to pure 32bit or pure 64bit thus unbreaking build on amd64-suse10 installed w/o 32bit backwards compatibility http://cvs.openpkg.org/chngview?cn=32655 The GCC multilib feature is a problematic one as not all platforms where GCC thinks it can support multilib really provide all prerequisites for this. GCC usually thinks that amd64-linux platforms support multilib (32 and 64 bit at the same time), but with mostly all default installations this isn't the case. Similar to other platforms like ix86-solaris. So, instead of letting GCC enable multilib with its own decision, make the multilib feature an explicit one and actually disable it by default (as within OpenPKG we don't want mix and actually cannot mix 32 and 64 bit code anyway). If one really wishes multilib with OpenPKG's GCC one now explicitly have to enable it with the with_multilib option. -- Thomas __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: OpenPKG great, but not for desktop?
Daniel Herrmann[EMAIL PROTECTED] wrote on 2006-11-29 10:03: So I ask you: Am I assuming correctly that OpenPKG is currently not for deploying desktop apps? As Ralf already explained in a rather lengthy message, the short answer is yes. However, this is not a limitation of the technology but the current community has little need for desktop apps - and probably little knowledge in building them. We welcome contributions and continuously seek for new activists in the OpenPKG Foundation ... -- Thomas Lotterer [EMAIL PROTECTED], Vice President and Director Engineering Production, OpenPKG Foundation e.V. __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Configuring Logfile rotation.
On Monday, 25. September 2006 at 2:40 pm, Bernhard Reiter[EMAIL PROTECTED] wrote: there is no manpage shtool-rotate on the system. GNU shtool is a highly modular application which can be found in various levels of completeness through the field. The shtool rotate command ships as part of the bootstrap, the manual page shtool-rotate does not. Readers have to install the shtool package to get a full featured installation including the manual page. The faq mentions a handbook under OpenPKG breaks with a few things from the good old Unix days. Why? but I havn't found it. Oops. AFAIK the handbook has been removed [...] Yes, it is very important to have answers to this questions around. I improved the FAQ [1] entry. [1] http://www.openpkg.org/documentation/faq/ -- Thomas __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Configuring Logfile rotation.
On Wednesday, 20. September 2006 at 10:04 am, Sascha Wilde[EMAIL PROTECTED] wrote: I'm seeking information on how to configure logfile rotation in OpenPKG, especially min size, and age of files to rotate, as well as the number of rotated versions to hold before deletion are of interest. It works almost identical for all packages supporting it. For package foo, look into $PREFIX/etc/rc.d/rc.foo file. You find some foo_log_* variables defined in the %config section and later on they are passed verbatim into shtool rotate in the %daily section. Have a look at openpkg man shtool-rotate Never modify the rc.foo file, it is not flagged config and will be overwritten on next update. Override the default by placing an identically named variable into $PREFIX/etc/rc.conf. I wasn't able to find documentation on that subject on http://www.openpkg.org/documentation/, in fact I couldn't find any decent information on the whole openpkg rc system. Have a look at openpkg man rc The faq mentions a handbook under OpenPKG breaks with a few things from the good old Unix days. Why? but I havn't found it. Oops. AFAIK the handbook has been removed because it was written for OpenPKG 1.x. However, the article [1] originally posted in Sysadmin Magazine some years ago received a major overhaul only one month ago and is very up to date now. Btw, Ralf refreshed the text after an inquiry by your collegue Bernhard R. ;-) I did find some variables in etc/rc.d/rc.fsl which look promising, but I'm unsure if fiddling with this file is TRTTD. (And having documentation of the variables would be neat in any case...) It is safe to modify the $PREFIX/etc/fsl/fsl.foo file. Everything you asked for in the first paragraph can be done with rc.conf. However, if you want to log to something else but files, do filtering or trickery like resuming logging after (re)moving the logfile without restarting the affected daemon etc., fsl is the place to go. Have a look at openpkg man fsl. Another useful command regarding the rc topic is openpkg rc --config [1] http://www.openpkg.org/documentation/article/ -- Thomas __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Upgrade Procedure OpenPKG 2.5 to OpenPKG 2.20060622 failed
Re Simon! On Saturday, 1. July 2006 at 6:54 pm, [EMAIL PROTECTED] wrote: I tried to follow the instructions given and have found a problem. # $prefix/bin/openpkg build -ZaKB | sh FATAL: errors occured while building: pine-4.64L-2.20060622: pine searches a frood called 'MTA' That means pine needs MTA, a virtual package that is provided by various MTAs namely sendmail, postfix, exim, ssmtp and openpkg-import::with_mta. I have seen that error message in cases where 1) a package requires an MTA and 2) multiple packages are listed in the repository being able to satisfy the requirement and 3) openpkg build doesn't know which one to take. You definitely hit 1 and 2 for sure. When doing upgrades, openpkg build is smart enough to take the MTA provider which is already installed, avoiding 3. However, the new -Za combo really is a reinstall and starts much closer at zero than a -Ua. It seems the implementation is incomplete as it is not smart enough to take the magic pick the existing MTA over to the reinstall logic. This seems to be a bug and I have to think about a proper resolution. In the meantime, here is a workaround: run # openpkg rpm -q --whatprovides MTA to figure out which of the currently installed package provides MTA. This should list postfix in your case. Then add a hint to openpkg build telling it to prefer postfix when multiple packages can be used to satisfy a requirement. In the end # $prefix/bin/openpkg build -ZaKB -H postfix | sh should do the job for you. Please try and tell, I'll have to update the release notes. -- Thomas __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
openpkg-import (Was: Re: Upgrade Procedure OpenPKG 2.5 to OpenPKG 2.20060622 failed)
On Sunday, 2. July 2006 at 3:44 pm, [EMAIL PROTECTED] wrote: It looks like openpkg-import is not included in the 2.20060628 branch. The package was omitted by intention. The openpkg-import package is only little more than an idea. In fact it breaks the fundamental concept of OpenPKG being self-contained and almost independent from the operating system. Some OpenPKG purists may want to create a new package class CRAP or even EVIL for it :-) Well, exceptions and relaxed rules introduced by practical use cases protect the package from obliteration ... -- Thomas __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Registry annoyances
Re Martin! On Wednesday, 28. June 2006 at 10:52 pm, [EMAIL PROTECTED] wrote: Hi, the OpenPKG registration process is still a big annoyance and hindering adoption/usage of OpenPKG a lot. We introduced the registry because we needed some statistics about the OpenPKG world. Past experience showed that unenforced feedback was close to zero. Talking not only about technical issues, I underestimated the complexity of the overall change and, probably most important, the aversion of our user base. We went the enforment route when we were close to a make-or-break decision regarding the future of OpenPKG. Granted, our mistake was the timing. The proceeding was too sudden and too complete, giving parts of the community a feeling of rudeness. It is a matter of fact that people are very sensible to any change which makes their world harder, slower, more expensive or otherwise worse from the point of their sole egocentric perspective. Some boil that down to the philosophic message change is bad. There are good reasons why even in a democracy tax payers are not asked whether they support a tax increase, culprits are not asked for their penalty etc. Finally, months after the introduction of the registry, OpenPKG still exists as an offering free of charge. You have to thank the registry and the people who use it. E.g. the stupid registration feature requires email validation within a short period of time (some minutes). This breaks much too often! Think about people doing something else in the meantime and especially consider the very commin smtp greylisting. The period was set to an hour already and if I remember this change has been made upon your request. Also a bit off topic, I do not accept people attempting to make their problems mine. Greylisting is sensitive to all kinds of timing issues and the people who use it (should) have made their decision to use that technology based on that design issue. Back to the topic, the registry must not assume message transfers happening close to realtime. UUCP still exists in 2006. The timeout has been extended to some hours now. An additional idiocy is that after the registration timed out the system dissallows to start over :-(( It seems a restart has been denied because the registration succeeded. We should consider improving the (error) messages. This is now the third time that I tried to register and the system is still not working reasonably. We constantly receive registrations so the process is feasible. Unfortunately, we cannot ask the people who failed because we do not know them. Gotcha. In case the fascist(*) registry process does not get relaxed very soon I will stop recommending OpenPKG as a solution and will move away my systems and OSS projects from using OpenPKG. I hope you are fully satisfied now and we can count on your evangelism. (*) I consider very tight timing requirements Has been discussed above. and removing of already working features (like unrestricted download of Imagine that: before the registry, every piece of OpenPKG was available free of change to anonymous users. At this point, any change is bad from the egocentric users point of view (dejavu, eh). Today OpenPKG is available free of charge to known users. The effort for users is to reveal their identity in form of a working E-Mail address. old versions Others simply discard old versions. We do, too. You probably should setup a mirror. You know we still support rsync also it is counterproductive for the registry idea. and breaking exisiting installations and setups as an unfriendly action. I must point out that this statement is unacceptable wrong. The concept ensures existing installations and setups do not break - they continue to run as they did before! It might not be possible to repeat pre-registry steps to create a new setup, so documentation and/or scripts might be updated. Various kinds of self created automatisms might fail to download new updates unless modified to work with the new registry world order. The obmtool being used by the Kolab community has been modified very shortly after the registry was established. It is refreshing for me to learn what users demand from a free offering. -- Thomas __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Release Notes (Was: [ANNOUNCE] OpenPKG project diverges 2-STABLE branch)
Please note the Release Notes [1] contain vital information about any release and snapshot, see heading New in OpenPKG-2-STABLE-20060622. On Thursday, 22. June 2006 at 5:19 pm, [EMAIL PROTECTED] wrote: From a maintenance point of view, this snapshot and possible future package updates on that branch supercede the OpenPKG 2.5-RELEASE and obsolete the OpenPKG 2.4-RELEASE. We added a Recommended Upgrade procedure from any OpenPKG-2.x-RELEASE section today which clearly demonstrates the usability improvements we did recently: - (simulated) openpkg build available immediately after bootstrap - ability to detect and configure update branch (openpkg release) - registry client included (openpkg register) - openpkg build now supports -Za (rebuild from Zero, all packages) - openpkg build -B option to create run-time tests to do/skip installs Quick and simplified instructions for Upgrades: $ openpkg rpm --rebuild openpkg-2.20060622-2.20060622.src.rpm $ openpkg rpm -Uvh openpkg-2.20060622-2.20060622.*-*-*.rpm $ openpkg rpm -e openpkg-tools openpkg-registry $ openpkg register --mode=post [EMAIL PROTECTED] $ openpkg build openpkg-tools | sh $ openpkg build -ZaKB | sh [1] http://cvs.openpkg.org/fileview?f=openpkg-re/releasenotes.txt http://cvs.openpkg.org/rlog?f=openpkg-re/releasenotes.txt Have fun! -- Thomas Lotterer [EMAIL PROTECTED], Vice President and Director Engineering Production, OpenPKG Foundation e.V. __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Invitation to meet the OpenPKG crew on Linuxtag 2006
Fellows! We have spare one-day tickets for Linuxtag [1] visitors. If you want to meet the OpenPKG crew please tell me so I can arrange you receive a ticket on time. The event takes place first week of May 2006 in Wiesbaden, Germany. In addition, if you know another fellow who wants to meet us just drop me a note and I'll be glad to send an invitation to him as long as stock lasts. I need his first and last name and a valid email address to send the electronic ticket to. [1] http://www.linuxtag.org/ I'm looking forward to see you at the show. -- Thomas Lotterer [EMAIL PROTECTED], Vice President and Director Engineering Production, OpenPKG Foundation e.V. __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Your influence to platform support
Folks! Please be aware that you have influence on the choice of platforms being supported by forthcoming OpenPKG releases. Registering an instance with the OpenPKG Registry acts much like casting a vote for the underlying CPU architecture and operating system. Don't miss that opportunity! DETAILS In the early years of OpenPKG the choice of which platforms are to be supported was driven by the requirements of the single orginal Project sponsor. In addition, if time and resources permitted, additional platforms were added by means of the project architect's favorite pick and the personal preferences of the release engineers. In the year 2005 sponsorship as it existed previously vanished. So did the rating of the sponsor's requirements. Before the end of that year both numbers reached zero. Simultaenously the OpenPKG Foundation e.V. was established and one of it's responsibilities since then is to operate the buildfarm being used to create a release. Obviously the Foundation gained sizably control over platform choice. By the end of the year 2005 the OpenPKG Registry was established as a quick and dirty hack to forcibly demand feedback from the community and to explore the scope of the outer OpenPKG world. The authors knew very well the crude proceeding wouldn't be loved by the community but previous attempts to get voluntary feedback failed both in data quality and quantity. All objectors and doubters please take note that the implementors of the Registry believe that this apparatus finally pays off for the whole community. The data collected is used as input for critical decisions regarding the future of OpenPKG. Hiding or faking data will eventually hurt the community. Please support the project and provide meaningful and complete information. This time you de-facto vote for your platform. Expect future analyses will be performed to further drive the project. Thank you! -- Thomas Lotterer [EMAIL PROTECTED], Vice President and Director Engineering Production, OpenPKG Foundation e.V. __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: FSL Log Rotation Examples
Bill Campbell[EMAIL PROTECTED] wrote on 2006-02-09 05:15:50:
On Wed, Feb 08, 2006, Doug Summers wrote:
Could someone post a quick example of how to rotate logs based on size
and/or age with FSL? I'm most interested in rotating after 60 days and
keeping all compressed archives.
You can find many examples in the %{l_prefix}/etc/rc.d/rc.* run
control files in the %daily sections. [...]
As Bill suggested, looking into existing packages is the easiest way getting
examples. I recommend you check out the sources thus getting every existing
use. You must look at both, rc.* and fsl.* files.
Note that fsl by itself does not rotate logs at all! It requires an external
mechanism to rotate, archive and often restart service. In the OpenPKG world we
usually use shtool rotate and fsl in concert. This tool has powerful
capabilities to decide when to rotate, how to archive and compress and it
allows execution of external programs prior and past rotation. And that tool is
under control of the same developers, so we can always make shtool and fsl a
working team :-)
Regarding fsl it should be noted in OpenPKG by default we always log to a plain
file, although fsl offers more options. The challenge with rotation is that the
application does not know when an external shtool rotate moved the log away.
The application still logs into the previously opened file. Few applications
can be tweaked to close and open their logging channels so the majority of
packages restart the whole service after rotation. Not ideal, but it works -
sadly some service behaves better with occational restarts anyway, think of
memory leaks and other uncleand resources.
In case you do neither want service restarts nor does the service offer a
mechanism to control log restarting (e.g. by sending a signal or pipe a command
through a network socket) then fsl offers help. To be more precise, fsl dumps
its logs through OSSP l2 (logging library) and inherits its capabilities from
there. Again, same developers :-)
Option 1: jitter=count
see - cvs, lighttpd, nagios, nessus-tool, nsd, openvpn, pound, powerdns,
spamassassin, squid
Counts the messages being written to the log and closes and opens the logfile
after every count writes just before the actual write is performed. Use
jitter=1 to close and open for every new message. This is very easy to
understand and use but the price is a performance penalty.
Option 2: monitor=seconds
see - dhcp-agent, gated, lighttpd, nagios, nessus-tool, nsd, openvpn, postfix,
pound, powerdns, powerdns, spamassassin, ucarp
Remembers the time when the last message was written to the log. Before every
new write the current time is checked and in case seconds or more time has
passed since the last write the state of the log file is monitored and in case
the original file disappeared a close and open is done before the write. Sounds
a little bit complicated but fsl cannot trigger actions by time because it is
under control of the applications it was implanted and that application does
not know about fsl (otherwise it could use OSSP l2 natively without fsl
wrapping syslog). So fsl can only act when it is called. The behavior is that
fsl keeps the log file open until the next message is to be written. This could
probably be a very long time and the opened log file might be moved, compressed
and deleted in the mean time. No problem, the check is performed before the
next write and we thoroughly evaluated that closing such a strange file does
not do harm to the application, fsl or the log file contents. Again the price
for using that feature is a performance penalty.
Find more details - openpkg man fsl
--
Thomas
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
obmtool (Was: Re: OpenPKG Registry launched)
There is a new obmtool [1] available from ZfOS [2] for use in the new OpenPKG Registry world order. New features are mirror support, choice of download tool with fallbacks and user/pass support. The latter especially understands and obeys the URL rewriting of those instances who utilize that feature after registration. Find ChangeLog and sample obmtool.conf alongside. Requires openpkg-registry-0.2.5, it won't rewrite URLs with previous versions. [1] ftp://ftp.zfos.org/comp/obmtool/ [2] http://www.zfos.org/ __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: OpenPKG Registry launched
Simon, Simon J Mudd[EMAIL PROTECTED] 2005-11-29 19:42:55 [EMAIL PROTECTED] COS4 openpkg]# /openpkg/bin/openpkg rpm -qa | grep openpkg awk: cmd. line:3: fatal: Invalid range end: /^([A-Z][A-Z0-9_]+[A-Z0-9]=[ !#$%(-_a-~]+)? *(#.*)?$/ openpkg-tools-0.8.37-2.4.0 openpkg-registry-0.2.1-20051128 perl-openpkg-5.8.7-2.4.0 openpkg-2.4.2-2.4.2 This is running on CentOS 4 (rhel4 clone and was running fine). I have registered and when I run openpkg register I get the following output: [EMAIL PROTECTED] COS4 ~]# /openpkg/bin/openpkg register awk: cmd. line:3: fatal: Invalid range end: /^([A-Z][A-Z0-9_]+[A-Z0-9]=[ !#$%(-_a-~]+)? *(#.*)?$/ thanks for reporting. We were unable to reproduce that problem but in fact that awk(1) statement had the potential to make trouble. We did test it on approximately twenty platforms and all succeeded, including RHEL4. Anyway, we tried to simplify the code in the hope it will be even more portable now. See http://cvs.openpkg.org/chngview?cn=26444, the fix made it into openpkg-registry-0.2.5-20051129 released a few minutes ago. __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: How to install
On Thu, Aug 11, 2005, Tim Gallagher wrote: I am running a Debian 3.1 Sarge install and have no idea how to install OpenPKG. I am trying to test out Kolab for a friend, the install is in OpenPKG rpm's. How can I install OpenPKG. Installing Kolab - http://wiki.kolab.org/index.php/Main_Page#Kolab2_Server Installing OpenPKG (not related to Kolab) - http://www.openpkg.org/tutorial.html - http://www.openpkg.org/showcase.html - http://www.openpkg.org/doc.html ... __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
closed user group chatting and logging
Hi, I want to setup a closed user group chat accessible by a variety of clients. Multiple (=3), individual users should authenticate, talk (=type, not voice) together and their discussion should be logged to a file. Tried a lot of OpenPKG packages and failed. IRCd does not have authentication at all. Tried ngIRCd but it only supports a single common user/pass pair and I did not find any client supporting this feature. Also tried jabberd but it is horrible unstable and does neither support group chat nor logging. Any chatters around here which can point me to a solution? I'll create/modify a OpenPKG package, of course. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: logging configuration
On Sun, Jan 16, 2005, Ralf S. Engelschall wrote: On Sun, Jan 16, 2005, F. Even wrote: Ralf S. Engelschall wrote: On Sat, Jan 15, 2005, F. Even wrote: Just add to your prefix/etc/rc.conf: postfix_log_numfiles=20 postfix_log_minsize= As already pointed out the postfix_log_minsize must not be empty because the calling program line unconditionally adds an option with expects this mandatory parameter. Set it to a very high number to effictevely disable the log rotation, e.g. Ah, ok, my fault. I should know that an empty argument is expanded away by the shell here. Well, then just use postfix_log_minsize=999G and you should be fine. Set it to zero to rotate every day no matter how small the log file is (even empty), e.g. postfix_log_minsize=0 -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Will there be a security update for cyrus imapd in openpkg 2.2?
On Fri, Nov 26, 2004, Steffen Hansen wrote: This one seems quite serious: http://security.e-matters.de/advisories/152004.html We will definitely create an UPD package. I can promise Monday. Maybe sooner. Thanks for pointing out. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Upgrading OpenPKG only
Re Stephan,
On Mon, Nov 01, 2004, Stephan Buys wrote:
Is it possible to upgrade OpenPKG-2003-06-06 to OpenPKG 2.[x ...]
yes, it is. But not that simple because versions before openpkg-20030802
behave like OpenPKG 1.x release and care must be taken when upgrading
from 1.x to 2.x, see the Release Notes [1]
I once wrote a little scriptlet for obmtool.conf which automates that
upgrade. It is attached and because it is mostly a shell script it can
be run without obmtool after little editing.
[1] http://cvs.openpkg.org/openpkg-re/releasenotes.txt
--
[EMAIL PROTECTED], Cable Wireless
%opkg
echo boot/build ${NODE} %${CMD}
PREFIX=/usr/${CMD}
#
# check for 1.3 to 2.0 upgrade conditions; setup intermediate step
#
@rpm
if [ -x ${MPX:-${RPM:-/etc/passwd}} ]; then
OPENPKG=`${MPX} ${RPM} -qa | ${EGREP} '^openpkg-[^-]+-[^-]+$'`
VERSION=`echo ${OPENPKG} | sed -e
's;^openpkg-\([^-][^-]*\)-\([^-][^-]*\)$;\1;'`
RELEASE=`echo ${OPENPKG} | sed -e
's;^openpkg-\([^-][^-]*\)-\([^-][^-]*\)$;\2;'`
if [ .${OPENPKG} != .openpkg-1.9.0-2.0.0 -a .${VERSION} != .${RELEASE}
]; then
echo ${VERSION} different from ${RELEASE}. Cannot handle this unknown
situation.
exit 1;
fi
VER=`echo ${VERSION} | sed -e
's;^\([0-9][0-9]*\)\.\([0-9][0-9]*\)\([sabp.]\)\([0-9][0-9]*\)$;\1;'`
REV=`echo ${VERSION} | sed -e
's;^\([0-9][0-9]*\)\.\([0-9][0-9]*\)\([sabp.]\)\([0-9][0-9]*\)$;\2;'`
TYP=`echo ${VERSION} | sed -e
's;^\([0-9][0-9]*\)\.\([0-9][0-9]*\)\([sabp.]\)\([0-9][0-9]*\)$;\3;'`
LEV=`echo ${VERSION} | sed -e
's;^\([0-9][0-9]*\)\.\([0-9][0-9]*\)\([sabp.]\)\([0-9][0-9]*\)$;\4;'`
cont=yes
if [ .${VER} = .${VERSION} ]; then
[ ${VER} -lt 20030802 ] cont=no
[ ${VER} -le 20040130 ] cont=intermediate
[ ${VER} -gt 20040213 ] cont=unknown
if [ .${cont} = .no ]; then
echo ${OPENPKG} must be upgraded to openpkg-20030802-20030802 ...
openpkg-20040130-20040130 first
exit 1;
fi
else
[ ${VER} -lt 1 ] cont=no
[ ${VER} -eq 1 -a ${REV} -lt 3 ] cont=no
[ ${VER} -eq 1 -a ${REV} -eq 3 -a ${LEV} -le 1 ] cont=intermediate
[ ${VER} -eq 1 -a ${REV} -eq 3 -a ${LEV} -gt 1 ] cont=unknown
if [ .${cont} = .no ]; then
echo ${OPENPKG} must be upgraded to openpkg-1.3.0-1.3.0 first
exit 1;
fi
fi
[ .${debug} = .1 ] echo DEBUG: OPENPKG=$OPENPKG VERSION=$VERSION
RELEASE=$RELEASE VER=$VER REV=$REV TYP=$TYP LEV=$LEV cont=$cont
if [ .${cont} = .intermediate ]; then
echo ${OPENPKG} is now upgraded to intermediate step
${MPX} ${RPM} -q /dev/null openpkg-tool ${MPX} ${RPM} -e openpkg-tool
@install openpkg-1.9.0-2.0.0
echo intermediate step rebuilding database
if [ .$CHECKONLY != .yes ]; then
${MPX} ${RPM} --db-rebuild
else
echo CHECKONLY: ${MPX} ${RPM} --db-rebuild [skipping]
fi
TRACK=
fi
if [ .${cont} = .unknown ]; then
echo this script does not know how to handle ${OPENPKG} - continue anyway
fi
fi
# start from scratch, upgrade within 2.1, from 2.0 or upgrade from 1.9 (=1.3
intermediate step)
@install openpkg-2.2.0-2.2.0 \
--tag=${CMD} \
--prefix=${PREFIX} \
--user=${CMD} --group=${CMD} \
--muid=1006 --ruid=1007 --nuid=1008 \
--mgid=1006 --rgid=1007 --ngid=1008
#
# check whether tag format works as desired
#
TAGFMT=`${MPX} ${RPM} --eval '%{?l_tag_fmt:%{l_tag_fmt}}'`
if [ .${TAGFMT} != .compat -a .${TAGFMT} != .loc -a .${TAGFMT} !=
.opkg ]; then
if [ .$CHECKONLY != .yes ]; then
echo TAGFMT not working. Got \${TAGFMT}\. Expected \compat\ or
\loc\ or \opkg\.
exit 1
else
echo CHECKONLY: TAGFMT not working. Got \${TAGFMT}\. Expected
\compat\ or \loc\ or \opkg\.
fi
fi
Re: Upgrading openpkg with .openpkg/build
Re Aaron! On Wed, Oct 20, 2004, Aaron Bostick wrote: [...] I have discovered I can upgrade my hosts to newer releases just by changing the index build uses when curling for packages. For example, every host has .openpkg/build with something like this in it: -f ftp://myrsyncserver/release/2.0/00INDEX.rdf So running openpkg build -Ua | sh - will upgrade 2.0 packages. This is a good approach to get UPDs within a release which are most likely security related and sometimes minor fixes. We take great care to keep changed packages compatible with previous versions so updating is a nobrainer in almost all cases. In the more recent history we tried to avoid changing configuration files on UPDs to avoid creation of .rpmsave backup files. So if I want to upgrade to 2.1, I just change the .openpkg/build file to say: -f ftp://myrsyncserver/release/2.1/00INDEX.rdf Then I run openpkg build -Ua | sh - and it recompiles everything under the new release. This will switch to a new RELEASE which might introduce all kinds of trouble due to incompatible changes in vendor applications and OpenPKG itself. Do not try this unattended. Yesterday we reanimated the good old upgrade [1] document to give a guideline for a Typical practice upgrading to a new OpenPKG RELEASE. I've upgraded a couple systems so far with this method with no problems. Are there any glaring issues [...] You find all the gory details in the Release Notes [2]. The good news is that there are no known issues within the 2.0 - 2.1 - 2.2 path with prevent you from doing your fast upgrade. This is no promise for the future. And if you want to see an example where this kind of upgrade would have failed browse the relase notes for 1.3 - 2.0 upgrade (we had reasons to increment the major number). [1] http://cvs.openpkg.org/openpkg-re/upgrade.txt [2] http://cvs.openpkg.org/openpkg-re/releasenotes.txt -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: problems with accessing cvs-server
On Wed, Oct 20, 2004, Andreas Schmidt wrote: i can't login to the cvs-server as anonymous: Fixed. We upgraded to OpenPKG 2.2 and the default of the CVS package changed to not run the pserver daemon by default. We should have better asked the experts ... :-) PS: michael, this seems to be an issue worth for the releasenotes.txt -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Problem with the Perl package (Installing kolab2 (20040817))
On Wed, Aug 25, 2004, Martin Brodbeck wrote: Ah, you moved from the Kolab list. Welcome. I tried to install a kolab2 snapshot but there seems to be a problem with the openpkg perl package perl-5.8.4-2.1.0.src.rpm. Trying to rebuild the src.rpm I got the following error message. [...] I use Fedora Core 2. Does somebody know what the problem can be? FC2 is fully supported. Please build manually and send me the full log along with a /bin/rpm -qa and /kolab/bin/openpkg rpm -qa output so I better know your environment. $ /kolab/bin/openpkg rpm --rebuild /path/to/perl-5.8.4-2.1.0.src.rpm 21 | tee log -- [EMAIL PROTECTED], Cable Wireless __ 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]
FYI: snmpdx issues (perl incompatiblity and dns probe)
Folks, there are two issues with the EVAL classified snmpdx package you should be aware of. INFINITE LOOP A compatiblity problem between snmpdx and perl. Problematic version combinations cause a infinite loop in snmpdx that consumes large amounts of CPU horsepower and fills the logging filesystem at a very fast rate as far as it will go. snmpdx perl = 0.2.8 = 5.8.3 ok = 0.2.8 = 5.8.4 problem = 0.2.9 5.8.x ok Please either - keep your old perl-5.8.3 or earlier version or - upgrade to snmdx-0.2.9 or later or - apply OSSP patch [1] for locally modified packages BIND PROBE Also note that today snmpdx-0.2.10 was released which adds a swBind probe for monitoring named(8). In order to get this new probe to work the statistics-file in named.conf(5) must be configured as shown in the CURRENT named package [2]. This is not the default case for any existing RELEASE. There are no plans for issuing an UPD bind package because a modified named.conf file will inadvertently create a named.conf.rpmsave and cause problems for people running automated update environments. [1] http://cvs.ossp.org/chngview?cn=4652 [2] http://cvs.openpkg.org/chngview?cn=18358 -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: FTP error
On Tue, Jul 27, 2004, Sivasakthi wrote: Re, I'm trying to download the files but the ftp error [...] I decided to use FTP Commanded to connect but what username and password [...] login as anonymous, any password including empty is valid. $ ftp ftp.openpkg.org Connected to master.openpkg.org. 220 ftp.openpkg.org OpenPKG Anonymous FTP Server (ProFTPD) ready. Name (ftp.openpkg.org:foo): anonymous 331 Anonymous login ok, send your complete email address as your password. Password: [just hit RETURN] 230- ___ _ __ 230- / _ \ _ __ ___ _ __ | _ \| |/ / ___| The world of 230- | | | | '_ \ / _ \ '_ \| |_) | ' / | _ cross-platform 230- | |_| | |_) | __/ | | | __/| . \ |_| | RPM-based Unix 230- \___/| .__/ \___|_| |_|_| |_|\_\|.org software packaging 230- _ |_| _ 230- [...] 230- Our local time is Tue Jul 27 09:03:27 2004. 230- Contact [EMAIL PROTECTED] in case of problems. 230- 230 Anonymous access granted, restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp Binary transport is important when grabbing the openpkg-*.sh bootstrap files for OpenPKG 1.3 and later. They start with shell script text but deeper in the file is binary data which will be destroyed when using ASCII transfers. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Whoson patch not applaying on postfix
On Sun, Jul 25, 2004, Bill Campbell wrote: On Sun, Jul 25, 2004, Alexander Belck wrote: When compiling postfix with[_whoson yes ... patch does not apply] I posted a replacement patch for this yesterday or the day before. I think there's a new version of postfix in the CURRENT tree that fixes this. Yes, Ralf took Bill's patch and not only created a CURRENT package but did a MFC [1], too, resulting in a UPD package [2]. [1] http://cvs.openpkg.org/chngview?cn=18269 [2] ftp://ftp.openpkg.org/release/2.1/UPD/postfix-2.1.4-2.1.1.src.rpm -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Howto upgrade a source-build OpenPkg-2.0 instalation
On Fri, Jul 23, 2004, Alexander Belck wrote: Alex, How should I proceed to upgrade all packages [from 2.0] to the equivalent of release 2.1 ? my approach manually upgrading a instance from 2.0 to 2.1 is: - read and understand the release notes [1] :-) - backup the instance, especially the etc, share and var directories. - make sure there's plenty of hard disk space available. - download and upgrade the bootstrap openpkg package. - upgrade/install make, binutils, gcc, perl and openpkg-tools packages. Assumed you're lucky with the gcc default options, which is likely to be the case, these steps can be automated by running openpkg rpm install openpkg-tools. This makes - see what openpkg build -Ua suggests and if it works and the output (which is a shell script) looks reasonably run it. [1] http://cvs.openpkg.org/openpkg-re/releasenotes.txt -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: issues with libpthread while bootstrapping
On Thu, Jul 22, 2004, Rangarajan, Mukund (Cognizant) wrote: I am trying to bootstrap OpenPKG on the new SuSe 9.1 platform and am running into a couple of issues. I am running SuSe Professional 9.1. ./lib/.libs/librpm.a(rpminstall.o)(.text+0x15bb): In function mktemp' is dangerous, better use [EMAIL PROTECTED]' /lib/libpthread.so.0: undefined reference to [EMAIL PROTECTED]' This is a known issue which is, along with a workaround, documented in the Release Notes. Search for nptl. We fixed this yesterday in CURRENT [2][3] and this is a candidate to be merged into an UPD RELEASE package. [1] http://cvs.openpkg.org/openpkg-re/releasenotes.txt [2] http://cvs.openpkg.org/chngview?cn=18217 [3] ftp://ftp.openpkg.org/current/SRC/openpkg-20040721-20040721.src.rpm and .sh -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: changing PATH value in rpmbuildsure
On Thu, Jul 22, 2004, Rangarajan, Mukund (Cognizant) wrote: Mukund, Is it possible to change the PATH value when executing openpkg rpmbuild [...] your assumption of PATH being controlled by OpenPKG during the build process is correct. We introduced a sane build environment in OpenPKG 1.1 because we did not want the build to depend on an arbitrary user environment. Without this added sanity the whole build process was much less predictable and reliable. We tried hard to isolate OpenPKG from the OS and to not let the build process pick up things from the system. If I print the PATH value (echo $PATH) within the spec file of a component (within the %build or %install steps), the value is different from the environemnt PATH value. I assume that this is because the value within the spec file is set during Openpkg installation. Is this a correct assumption? Is it possible to override this value? If so, how? You cannot pass environment settings from the user's shell into the build process. This works as designed. However, you can set any shell variable inside the spec file and you can try to override certain variables in rpmmacros. Start looking at %l_sane_env and find it depends on %l_build_path which is the place to hack. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: help using openpkg [newbie question]
On Wed, Jul 21, 2004, Simon J Mudd wrote: Re Simon, I'm using Whitebox Linux (a RedHat Enterprise 3 clone) [...] If you know better than rpm that a binary package can be used on a particular system or you just want to give it a try then convince rpm using the --ignoreos or --ignorearch options. The situation you are describing sounds promising when ix86-rhel3 binaries are used. 2. After building and executing [...] However this whole process is manual [...] I've since seen that there is openpkg-index and openpkg-build [...] First install the openpkg-tools package. It requires make, gcc and perl. Having only the bootstrap available the whole thing can be setup using $ openpkg install openpkg-tools With the tools being installed use something like $ openpkg build apache | sh The build tool reads the indices from the OpenPKG ftp server based on the bootstrap you're using, takes package options as arguments, computes the dependency chain and writes the commands you would have to enter manually to stdout. The example above directly pipes these commands into the shell. Try these and learn: $ openpkg build apache $ openpkg build -D with_mod_ssl=yes apache $ openpkg man build I'd like to keep OpenPKG uptodate. [...] Frequently run $ openpkg build -Ua | sh Be aware that updates for release are created very carefully and in almost all cases they can be applied and everything will continue to work. In contrast, if you run CURRENT then every update can completely change world order ... You find two paragraphs describing this at the top of the Release Notes below General Notes about Upgrading. [1] http://cvs.openpkg.org/openpkg-re/releasenotes.txt -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: help using openpkg [newbie question]
On Thu, Jul 22, 2004, Simon Mudd wrote: Re, I'm using Whitebox Linux (a RedHat Enterprise 3 clone) [...] I also tried to adjust the shtool [...] producing the following 2 files: openpkg-2.1.0-2.1.0.ix86-rhel3.0-ope.rpm openpkg-2.1.0-2.1.0.ix86-rhel3.0-ope.sh This installed [...] but binary rhel3 packages gave me an error [...] please examine the content of the platform file (it has no newline). Our reference machine reads: $ echo `cat /openpkg/etc/openpkg/platform` ix86-any-rhel3 PS: why do you fight so hard with binaries when sources work well? -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: uninstall openpkg?
On Mon, Jul 19, 2004, v8625 wrote:
Dear v8625,
I updated kernel on RedHat 9.0 [...]
as discussed on this list using /usr as a prefix was at least a brave
action. You must assume important parts of you OS were overwritten by
OpenPKG. I don't know whether it is worth the time repairing the system,
it is likely a reinstall is the faster route to go. But if you like hard
work, here are some hints: the FAQ lists where OpenPKG links itself into
the OS, see http://www.openpkg.org/faq.html#entry-points. Usually do a
rm -rf $PREFIX does huge parts of the job, but take care with your
particular prefix because it contains lots of non-OpenPKG files from
your OS! Assuming you have saved the OpenPKG binary RPMs you used to
ruin your system do a openpkg rpm -qplv *.rpm to query the files in
them. These are the files you want to get rid off. If they are surplus
files, remove them. If they replaced OS files, reinstall the OS package.
How do you know which OS package? /bin/rpm -qf filename will tell
you. Needless to say: both the openpkg and the OS rpm queries cannot be
performed on this defective machine and require another working helper
machine. You can query a OpenPKG RPM with any openpkg rpm command,
the application doing the query and the RPM to be sniffed do not need to
share a common prefix, arch or os, i.e. a Solaris /openpkg/bin/openpkg
rpm -qplv can query a FreeBSD binary RPM build for /cw. That means that
the helper machine can be an arbitrary Unix device and you can use our
prebuild binaries to get a fast start. Regarding the OS rpm queries all
I can offer you is the output of our reference RHL9 machine. Also to
recover all libraries used by the system's /bin/rpm, here's what I found
out on our machine using
$ /bin/rpm -qf `ldd /bin/rpm | awk '// { print $3 }'` | sort -u
bzip2-libs-1.0.2-8
elfutils-libelf-0.76-3
glibc-2.3.2-27.9.7
popt-1.8-0.69
rpm-4.2-0.69
Again hard work to be done: because /bin/rpm is not working you have to
watch out and copy the associated files from a good setup ...
Good luck!
--
[EMAIL PROTECTED], Cable Wireless
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
openldap, sasl, apache chicken and egg problem (Was: Re: More problems with apache)
On Wed, Jun 23, 2004, Alexander Belck wrote: Alex, I'm lazy. 2) openldap - sasl - apache chicken-and-egg problem Please browse or search the mailing list (i.e. MARC), this was discussed before. Hint: http://marc.theaimsgroup.com/?l=openpkg-usersm=107091431817004 -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
apache suphp=yes problem (Was: Re: More from apache)
On Wed, Jun 23, 2004, Alexander Belck wrote: Alex, [apache build problems with_suphp yes] at the end apache was build and a rpm -qip apache-...rpm includes: apache::with_suphp = yes Does I miss some prerequisit again ? Is mod_suphp build eaven with the above messages ? The rpm -qi shows the options you fed into the build process. This is no warrant that everything worked as expected. In this case the ultimate answer is what the apache binary lists as it's contents: $ $PREFIX/sbin/apache -l | grep su mod_suphp.c suexec: enabled; valid wrapper $PREFIX/sbin/suexec In case mod_suphp is missing please try the latest CURRENT package. We always fix that first. We might already have. Otherwise we have to. If the problem vanished in CURRENT we can merge the fix into the release and provide a update package. Please tell me about your findings. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Apache and PHP
On Wed, Jun 23, 2004, Alexander Belck wrote: Alex, To build apache with php it requires php, so I build and installed php first. only the with_suphp requires the php package. Even mod_php uses the php that is embedded into the apache package and does not require the php package. openpkg rpm -Uhv /opkg/RPM/PKG/apache-1.3.29-2.0.3.ix86-rhl7.3-opk.rpm Preparing...### [100%] file /opkg/bin/php from install of apache-1.3.29-2.0.3 conflicts with file from package php-4.3.4-2.0.0 What am I doing wrong ? I tried to reproduce the problem but failed. Building apache-1.3.29-2.0.3 with_suphp, with_mod_php or both does not produce a $PREFIX/bin/php file. Which options are you using? Please send me the full command line. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: openldap, sasl, apache chicken and egg problem (Was: Re: More problems with apache)
On Thu, Jun 24, 2004, [EMAIL PROTECTED] wrote: Re Alex, On Wed, Jun 23, 2004, Alexander Belck wrote: I will have my credential in OpenLDAP and will uses sasl to allow postfix check authentications against the LDAP, so just for this I build OpenLDAP --without_sasl sasl --with_ldap I know a project that does exactly this, using apache/mod_auth_ldap to login to a webinterface where mod_php_openldap changes user information stored in openldap and postfix looking them up. Excerpts from the setup: openldap-2.2.5-2.0.0 #no options sasl-2.1.17-2.0.0 --with=ldap --with=login postfix-2.0.18-2.0.0 --with=ldap --with=sasl --with=ssl apache-1.3.29-2.0.0 \ --with=mod_auth_ldap \ --with=mod_php \ --with=mod_php_openldap \ --with=mod_ssl Complete setup see ftp://ftp.zfos.org/brew/kolab/CFG/kolab-20040217-2.0.0/obmtool.conf -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Package dependency missing ?
On Tue, Jun 22, 2004, Alexander Belck wrote: Re Alex! Due to build perl-* I tryed to build x11 with openpkg build x11 | sh where I got a lot of errors starting with: ** ERROR: SOME X11 INFORMATION COULD NOT BE DETERMINED!! [...] ** Unfortunately, some information is missing here. [...] Currently OpenPKG does not have it's own X11 libraries, neither client nor server. Therefore the OpenPKG x11 package searches the OS for X11 client libraries and tells other packages requiring that information where to find it. What should I do ? What have I missed ? You need to install the X11 client libraries provided by your OS vendor. Our release engineering maintains a list of Operating System Prerequisites which logs what we installed in both a human readable format and a machine generated package list. Find it at http://cvs.openpkg.org/getfile/openpkg-re/osprereq.txt -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
fixing curl-7.12 on FreeBSD 4.0 (Was: Re: 1.3 to 2.0/CURRENT upgrade on FreeBSD 4.0)
On Tue, Jun 22, 2004, F. Even wrote: Re Frank. Thomas Lotterer wrote: On Tue, Jun 22, 2004, F. Even wrote: If the error persists the first actions digging down are a man strtoll and a look in libc having that function defined [...] That looks to be the problem: [EMAIL PROTECTED]:/usr/lib] nm /usr/lib/libc.a | egrep 'T strtoll' [EMAIL PROTECTED]:/usr/lib] ...and on a 4.7 box: bash-2.05b# nm /usr/lib/libc.a | egrep 'T strtoll' T strtoll Is there any way I can fix this short of bringing the box down and recompiling everything? Any particular packages I can install? Could I attempt to copy the library over from a newer box? Recompiling won't help because the missing function will be missing again. Unless you participate in a longest uptime contest [1] upgrading is the way to go, which is especially easy in the FreeBSD world. Well, risk increases when you previously skipped upgrades for years ;-) I leave this option for your consideration. The affected package is the OS's libc which is such a integral piece of the OS that I would never replace that file with a copy taken from somewhere else. Unless you're under heavy time pressure I would prefer to fix OpenPKG, in this particular case curl. That application is also available as a separate package which we need to fix and finally import that fix into the bootstrap. Please try to build the latest CURRENT curl 7.12 [2] package using the latest 1.3 RELEASE bootstrap [3]. Redirect stdout/stderr to a file and search it for checking for strtoll. I have to know whether the detection of strtoll(3) availability fails or the action in case of a missing strtoll is broken. So far, all of our systems but hpux11.11 come with that function but both curl and the bootstrap also work on HP/UX. So I assume the problem is with the detection. Please send me (not neccessarily the list) the output log you created. [1] i.e. http://uptime.netcraft.com/up/today/top.avg.html [2] ftp://ftp.openpkg.org/current/SRC/curl-7.12.0-20040609.src.rpm [3] ftp://ftp.openpkg.org/release/1.3/UPD/openpkg-1.3.1-1.3.1.src.rpm -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: RH7.3 and OpenPKG 2.0
On Tue, Jun 22, 2004, Alexander Belck wrote: Alex! Should I expect any known problem using OpenPKG over RH-7.3 ? RHL9 is a obsoleted platform in OpenPKG 2.0 which means there are no binaries available for anything but CORE packages. It is very likely that we'll throw out our machine past the OpenPKG 2.1 release or install another OS on it which will inhibit us reproducing problems. The largest problems you'll face will be vanished support by the vendor and lack of support by the community. The latter includes the various developers of all the open source applications which might introduce or already have requirements this old OS doesn't satisfy. Experience shows operating systems die slowly, you'll can continue to be happy with it for some more years. So far I build tha basic openpkg-2.0.3 rom source, openpkg-tools and gcc with no problems, [...] OpenPKGs approach building from sources will help you further extend the life of your existing environment. (Wow, what a marketing rubbish: watch out if you can mark a cross at the bullshit bingo [1] today :-) Finally, we do not forbid to ask questions or post patches ... [1] http://www.perkigoth.com/home/kermit/stuff/bullshitbingo/ -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
updated 1.9 intermediate package for upgrade procedure 1.3 - 2.0 available (Was: Re: openpkg 1.9 rpm install error)
On Mon, Jun 21, 2004, F. Even wrote: [...] seem then that the 1.9 bootstrap would need an upgrade I created the upgrade companion packages and added them to the ftp download area ftp://ftp.openpkg.org/release/2.0/UPD/ openpkg-1.9.3-2.0.3.src.rpm openpkg-1.9.2-2.0.2.src.rpm [*] openpkg-1.9.1-2.0.1.src.rpm [*] [*] belated and just for completeness See also http://cvs.openpkg.org/chngview?cn=17591 and http://cvs.openpkg.org/openpkg-re/upgrade.txt = 1.44 Thanks for pointing out. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: What happens to openpkg-tools in 2.0 ?
On Mon, Jun 21, 2004, Alexander Belck wrote: To build the packages I used openpkg-tools in ver 1.3 that could check dependencies and build them first if needed. OpenPKG 1.x had openpkg-tool and OpenPKG CURRENT (to be used for 2.0, too) has openpkg-tools (note the 's'). Find more details searching http://cvs.openpkg.org/openpkg-re/upgrade.txt for openpkg-tool. I just updated that document to reflect the change from openpkg-tool to openpkg-tools where appropriate. See http://cvs.openpkg.org/chngview?cn=17592. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
1.3 to 2.0/CURRENT upgrade on FreeBSD 4.0 (Was: Re: openpkg 1.9 rpm install error)
On Tue, Jun 22, 2004, F. Even wrote: It dies in pretty much the same place trying to go from 1.9.1-2.0.1. OK, I assume you give 1.9.3 or a very recent CURRENT a try, too. [EMAIL PROTECTED] rpm --rebuild openpkg-1.9.1-2.0.1.src.rpm snip main.c:1014:2: #error lack of strtoll() needs fixing If the error persists the first actions digging down are a man strtoll and a look in libc having that function defined using $ nm /usr/lib/libc.a | egrep 'T strtoll' T strtoll -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: What happens to openpkg-tools in 2.0 ?
On Tue, Jun 22, 2004, Alexander Belck wrote: Alexander, I couldn't find the openpkg-tools source in any of the 2.0 ftp directories. I do found a package in the CURRENT branche with this name. Should I use this one? Is it intencionaly not in the 2.0 branch? Yes and yes. The openpkg-tool has a file conflict with OpenPKG 2.0 and was omitted from the release intentionally. The new openpkg-tools package was not ready at that time so it was not included in the release intentionally. I'm not upgrading, I'm installing 2.0 from scratch, so how should I proceed if the sources for 2.0 do not provide the openpkg-tools. Is there an other sugested way to get the packages and all there dependencies for building ? Start with the latest bootstrap from the RELEASE and the openpkg-tools from CURRENT. As of today this means: ftp://ftp.openpkg.org/release/2.0/UPD/openpkg-2.0.3-2.0.3.src.sh ftp://ftp.openpkg.org/current/SRC/openpkg-tools-0.8.12-20040617.src.rpm The openpkg-tools package has dependencies to other packages and the bootstrap knows how to download and install them to satisfy these requirements and finally install openpkg-tools. After that process has finished you can continue using openpkg build as you already know from OpenPKG 1.x -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: How to Enable Software to start on boot
On Fri, Mar 19, 2004, Matthias Kurz wrote: David! On Fri, Mar 19, 2004, David M. Fetter wrote: What is the proper way to enable various pieces of software installed under OpenPKG? Whether the services are enabled or disabled by default is controlled by $openpkg_rc_def [...] Matthias already explained a lot. You find three paragraphs regarding this topic in http://cvs.openpkg.org/openpkg-re/upgrade.txt when searching for openpkg_rc_all. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: how to keep rpm-tmp.*
On Tue, Mar 16, 2004, David M. Fetter wrote:
How do I get the rpm rebuilds to keep the rpm-tmp.* file around so I can
look for information on why something failed? It looks like when I do a
rebuild even if it fails the rpm-tmp.* file is automatically removed
before I have a chance to review it.
David,
the --rebuild is essentially a fetch (--fetch foo.src.rpm), install
SRPM into %{l_prefix}/RPM/PKG/foo (-Uvh foo.src.rpm), cd to that
directory and build binary (-bb foo.spec). You can do these steps
manually and (re)gain control over the build process between each
step. The build binary instruction is even a whole bunch of steps
which can be executed individually. See package life cycle at
http://www.openpkg.org/doc/slideset/openpkg.html/slide-015-l.html
Having the SRPM installed aka unpacked you can do the %prep (usually
tar and patch) and %build (usually configure and make) step executing
a rpm -bc foo.spec. If you change something in the temp directory to
give it a try and want to repeat the %build step without executing the
(destructive!) %prep step again, use rpm -bc --short-circuit foo.spec.
--
[EMAIL PROTECTED], Cable Wireless
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Error Bootstrapping on RHEL3
On Sat, Mar 13, 2004, David M. Fetter wrote: Dear David, I'm getting an error when attempting to bootstrap OpenPKG-2.0 on RedHat Enterprise Linux 3.0. The error is as follows: ./lib/.libs/librpm.a(rpminstall.o)(.text+0x12a8): In function `rpmInstall': /usr/lib/nptl/librt.so: undefined reference to [EMAIL PROTECTED]' [...] I remember having seen such an issue in the past. It was a superflous or missing vendor package. You can find the packages we used for release building under http://cvs.openpkg.org/getfile?f=openpkg-re/osprereq.txt It shouldn't be too hard to find the difference. My memory tells me the issue was related to /usr/lib/nptl/librt.so which now no longer exists on our build machine. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: What is id or tag for?
On Thu, Mar 11, 2004, David M. Fetter wrote: I looked through the online documentation but can't seem to find any reference as to what the id or tag identifies. [...] Most of the mystery was already revealed. You find information in the news.txt [1] and upgrade.txt [2] documents. Search for the terms tag and new tag feature. [1] http://cvs.openpkg.org/openpkg-re/news.txt [2] http://cvs.openpkg.org/openpkg-re/upgrade.txt -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: OpenDST - some distribution ideas
On Wed, Feb 25, 2004, Stephan Buys wrote:
Hi all,
We are interested in creating a LiveCD for the Kolab server and I was
wondering what the absolute minimum system requirements would be to get
OpenPKG running? And possibly run most of your distributions' functions
from within OpenPKG.
A LiveCD will not be easy to create. The %{l_prefix}/var directory
must be writable. Because nobody I know of has ever tried running
OpenPKG from a read-only media other places might be found that need
write access - or fixing ;-)
As far as I know a complete Kolab install takes something like 500MB disk
space not including the RPMs. Too much for the average memory filesystem.
My suggestion for a (Knoppix-like) self contained bootable CD:
- do a union/translucent mount
drawback: hard to create
My suggestion for a mount-into-existing-system CD:
- create binary RPMs
- let the user to create a symlink to a huge disk space
- boostrap/install using binary RPMs (maybe using obmtool)
drawback: existing system is touched, see entry-points below
Apart from the following utilities:
uuencode
uudecode
These are no longer needed with OpenPKG 2.0
- I guess you also need to set up a user database /etc/passwd (for the Kolab
users)
- Cron
- And a couple of other utils?
see http://www.openpkg.org/faq.html#entry-points
/etc/openpkg is new to OpenPKG 2.0
Another question, would it be possible to run OpenPKG without a prefix? So that
our %l_prefix == ?
The potential here would be to create a couple of Skeleton OS's like a barebones
Linux or BSD system, and run the rest from within OpenPKG...
Is this in any way feasible?
An empty prefix, won't work because many code pathes within various
OpenPKG scriptlets change the working directory and assume access to
%{l_prefix} through an absolute path. Hashpling aka shebang (#!/...
at the top of a script) accept relative pathes but they will fail if
not executed from within the proper directory. For the same reasons, a
prefix with a relative path won't work, too.
--
[EMAIL PROTECTED], Cable Wireless
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: whereis openpkg-tool in 2.0 release?
On Tue, Mar 02, 2004, David M. Fetter wrote: David, I don't see the openpkg-tool in the SRC repository for the release [...] Please hunt for string openpkg-tool in http://cvs.openpkg.org/openpkg-re/upgrade.txt and have a look at packages dropped from release. Short info is: openpkg-tool is available as CURRENT package. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: NIS {N/M}
On Fri, Feb 20, 2004, David M. Fetter wrote:
Nevermind. My error. ;-)
Good for us to hear that :-) I was just verifying. To get an idea what
OpenPKG thinks what most of the user/group names/ids are, try this:
$ ${PREFIX}/bin/openpkg rpm --eval '%{l_value -s -a}'
Use uppercase -A to dump even more variables.
PS: stripp off '/openpkg ' if running 2.0 or 20040130
--
[EMAIL PROTECTED], Cable Wireless
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: multiple apaches
On Mon, Feb 16, 2004, Clemens von Musil wrote: Clemens, I want to install an openPKG environenment with apache and openLDAP on a machine, that allready runs those two servers. Esepecially for the apache would a two-instances-on-one-machine-solution be extremely comfortable to me. What I read is, that all openPKG instances on one machine are completely seperated from each other. Doesn't that mean, they have different (virtual) ip-addresses for different servers, listening on the same port? The ip:port combination must be uniqe for any services to be addressed predictable. Use a different ip, different port or both. It is not a problem for a machine to listen to multiple addresses today. I've seen a device in our datacenter that has over 4200 IP addresses in use on a single NIC. Some protocols carry additional information in their requests that allow a single service to behave differently upon request and look like being multiple services. The HTTP protocol supports so called name based virtual hosts and, of course, apache has this feature implemented. If yes... I'm not able to keep two apaches running this way. Can anybopy point me the right direction? There are philosophical issues to be addressed which I do not want to discuss in depth here. If all your servers can be run by the same apache binary (having the same modules, script languages, database interfaces ... built in), are under the same administrative/organizational scope, will be maintained simultaneously in the future etc. you might only install one apache and configure virtual hosts. Even name based virtual hosts. Another requirement might be file system isolation between any two services so one cannot view or alter data and code from the other. Use chroot environments in this scenario. Available on almost any UNIX. A more secure solution would be full isolation between any two services by using FreeBSD jails or Linux vserver. The toughest virtual isolation is use of hardware emulation like bochs or vmware in the PC world or machine paritioning available in Solaris and AIX. This allows multiple operating systems to run concurrently on the same hardware. This is the server consolidation prayer. Finally, the toughest isolation is use of separate hardware for any service. This is the appliance prayer. The OpenPKG way of doing it to install multiple instances on a single machine. They are logically isolated however protection against each other is the task of the OS based on the administrative/organizational rules being deployed. The tutorial at http://www.openpkg.org/tutorial.html might help you doing the OpenPKG part of the game. Install every piece of softare into each instance (make, gcc, ...) for maximum independence. Assume you name your two instances /apache1 and /apache2 then edit each config /apache?/etc/apache/apache.conf. Example for apache1: Listen 10.1.2.3:80 NameVirtualHost 10.1.2.3:80 VirtualHost www.example.com:80 ServerNamewww.example.com ServerAlias example.com ServerAdmin [EMAIL PROTECTED] ServerSignature off DocumentRoot /apache1/share/apache/www.example.com/ Directory /apache1/share/apache/www.example.com Options None AllowOverride None Order allow,deny Allow from all /Directory /VirtualHost Watch out to run the correct rpm and rc all the time! Example: $ /apache1/bin/rpm -Uvh apache-*.rpm #install 1st apache $ /apache2/etc/rc apache start #launch 2nd apache -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: apache -current
On Thu, Feb 12, 2004, Julien TOUCHE wrote: few comments on an apache setup with current/solaris9 (php part) [...] - why gdbm in apache, by default ? (with_gdbm_ndbm) http://cvs.openpkg.org/chngview?cn=14710 -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Some Questions
On Thu, Feb 12, 2004, David M. Fetter wrote: David! I have a series of questions after reading through the FAQ, Tutorial and some of the handbook. They are: 1. Is the 2.0 release currently on schedule for Q1/2004? Yes. 2. Is there a script of some sort that will automatically rebuild and install the src rpm's (i.e. something that will find the dependencies and install in the proper order)? We do not have a ideal solution for this. The best we can offer is the openpkg-tool package which contains a perl script which comes close to what you want. However, there are many real life scenarios that make the job of the script hard, i.e. retaining with_XXX options when upgrading, upgrade a library and know which applications to rebuild, working in mixed Release/ CURRENT environments ... just to name a few. Not all situations have be thought of, coded and debugged. Some do not work by design (either tool and/or OpenPKG). This is an area we have to improve OpenPKG a lot. 3. Should I install the openpkg rpm over the bootstrapped openpkg? How does the openpkg rpm info get inserted into the rpmdb otherwise? There is no need to install openpkg*rpm over openpkg*sh. The bootstrap process ensures openpkg puts itself into the rpmdb. This is dirty and tricky and I believe it took Ralf something like three months to make it happen when OpenPKG was born. 4. What is the best way (or is there one) to perform a mass system bootstrap/install across many systems? OpenPKG does not come with a automated deployment solution. There are a couple of options. Of course, you can create your own scripts or integrate into your existing deployment solution, if you already have any (i.e. ZENworks for Servers, cfengine, ...). Use openpkg-tool to automate parts of the deployment solution. My personal solution is a script called obmtool which is currently published as part of OpenPKG/Kolab integration. Its only a configuration file containing a shell script and a main shell script offering functions to reduce complexity of the config. See http://www.zfos.org/ for an example. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Some Questions (two more)
On Thu, Feb 12, 2004, David M. Fetter wrote: Ok, so I have two more questions here. :-) David, 5. Will OpenPKG work with apt-get (i.e. we setup our own repository and use apt on our remote hosts to grab their appropriate updates)? We tried and failed. Besides some technical difficulties we found that apt-get seems to work only good with binaries which violates OpenPKG philosophy preferring building from source. I'm not sure if we can ever get this to work properly. 6. Is it stable to use the current src rpm's with openpkg 1.3 or is it advised to wait until 2.0 is released as stable? We do desire good stability in our environment. Regarding OpenPKG itself I would recommend testing CURRENT now and deploying 2.0. There is a obvious risk in hundrets of vendor packages being updated which are not under our control. So anything can happen. Our build farm tests build, install and erase only. Labs can only test a fraction of the overall possible functions. Only practice can tell. I believe this is the same risk as you would have doing the configure; make; make install triple manually or download/ purchase any BSD system or Linux distro. If you prefer the bugs already known path then go for 1.3. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Problem building imapd-2.2.3 on Solaris9
On Mon, Feb 02, 2004, Christopher M. O'Malley wrote: Problem in the .spec file, I suspect, but I'm not sure how to fix it.. (not sure what the working directory is at that point when it fails..) Anyone else seen/fixed this? Thanks for the report. Ralf fixed the building. Now go for the run-time tests. I've heared this package doesn't work since the last vendor upgrade and we'll need to fix it soon if you find problems. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: What are OpenPKG's post-Red Hat Linux 9 plans
On Thu, Jan 29, 2004, Dennis McRitchie wrote: Hi, What are OpenPKG's plans for supporting a Red Hat Linux beyond Red Hat Linux 9? The choices appear to be 1) Fedora Project 2) Red Hat Enterprise Linux yes :-) OpenPKG v1.3 does support RedHat Linux 9 OpenPKG CURRENT almost runs on all of them OpenPKG v2.0 will fully support RedHat Fedora Core 1 OpenPKG v2.0 will fully support RedHat Enterprise Linux 3 ES Currently busy building packages on them, see http://www.openpkg.org/status.cgi -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Can't browse to https://rt.openpkg.org/
On Thu, Jan 29, 2004, Dennis McRitchie wrote: When I tried this morning, I got: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /. Reason: Could not connect to remote machine: Connection refused Apache/1.3.27 Server at rt.openpkg.org Port 443 Thanks for pointing out, Dennis. I shut down our bugdb (based around rt) yesterday. The reason was a spammer successfully injected a message that ended up in two machines talking to each other. One was sending acknowledgements, the other bounced them and the bounce was ack'ed. Perfect loop, see http://marc.theaimsgroup.com/?l=openpkg-devm=107524936523920w=4 Forensics prooved it can happen again until we improve some filter rules and/or softare in our setup to be more picky in what they accept. But our resources are entirely bound to OpenPKG v2.0 release engineering. So I have to defer bringing the service back up for a indefinite amount of time (worst case until shortly after the release). This is especially annoying as we have to resolve some OpenPKG v2.0 development and ALPHA deployment issues. Sorry, we have to stick to the mailing lists, text editor, paper and whiteboard until the root cause of the problem is eliminated. (technically speaking. We won't eliminate the spammer ;-) -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Can't browse to https://rt.openpkg.org/
On Thu, Jan 29, 2004, Dennis McRitchie wrote: Thanks Thomas. I just sent a new ticket to [EMAIL PROTECTED] (description of new oracle-barebone package submission) but did not get an acknowledgement. Should I temporarily send new tickets to openpkg-dev instead? Dennis Yes, please. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: OpenPKG ver 2.0
On Wed, Jan 21, 2004, [EMAIL PROTECTED] wrote: Cópia Thomas Lotterer [EMAIL PROTECTED]: On Tue, Jan 20, 2004, [EMAIL PROTECTED] wrote: I must search in previus OpenPKG emails. What I'm interested is a port from a KDE project (I gues) that within others should easyer smtp authentication. Kolab? YES! Can I install Kolab over OpenPKG 1.3 ? I got some answers from the list that I can mix some packages from the 1.3 and CURRENT branch, but I did not understand what Ralf mean with 'just use the bootstrap openpkg package and your particular other package from OpenPKG CURRENT'. Is this the openpkg utility from the openpkg-tool ? Alex, bad news. You cannot install Kolab over OpenPKG 1.3. The reason is that the Kolab developers took a lot of OpenPKG v1.1 or v1.2 and not only added a kolab package but also did some huge modifications to the OpenPKG packages which were maintained separately. So the two projects diverged. But there are good news as well. In 2003Q3 we integrated all Kolab changes back into OpenPKG CURRENT and even created a OpenPKG kolab package. We won't merge any of these changes into 1.3. But it is now possible to run Kolab with CURRENT and all that stuff will be included in OpenPKG v2.0. Even better news for you is the existence of a CURRENT snapshot of packages which were set aside from the everchanging ftp.openpkg.org. An installer to replace the QIM was added, too. And, unlike OpenPKG CURRENT, binaries are available. Goto http://www.zfos.org/ and find kolab-1.0.14-20031126 -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: FSL and Perl
On Tue, Jan 20, 2004, Stephan Buys wrote: On Tuesday 20 January 2004 12:50, Thomas Lotterer wrote: On Tue, Jan 20, 2004, Stephan Buys wrote: Could you provide me with a short C program that would demostrate how to use FSL directly? I could then provide the Perl wrapper for that C code. The fsl tarball contains a fsl_test.c. It contains no fsl specific code! Why? Because fsl emulates syslog(2) API. To integrate fsl, see SYNOPSIS in the fsl.pod file. As I suspected, so I guess the challenge here is to get the Sys::Syslog module of Perl to also use fsl. I noticed that there were no options for the OpenPKG perl package to use fsl, maybe this is the right place to start? I would love to see a with_fsl option there but I was afraid implementing it would cause havoc to all perl modules so I kept my hands off. Go for it! -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: How to activate OpenPKG services
On Tue, Jan 20, 2004, [EMAIL PROTECTED] wrote: So far so good, but while does the rc command doesn't also use a rc?.d structure [...] Because it has to work equally well on BSD, Linux and Solaris. BSD does not have run levels other than single-user and multi-user and the Linux world doesn't seem to be very unified in this area, i.e. Gentoo's run-levels are not driven by numbers and names but by dependencies. Tough facts for a cross-platform approach like OpenPKG. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: OpenPKG ver 2.0
On Tue, Jan 20, 2004, Ralf S. Engelschall wrote: On Tue, Jan 20, 2004, [EMAIL PROTECTED] wrote: I'm interested in a package that is only avaiable in CURRENT In such a situation you usually can install OpenPKG 1.3 [...] Note that openpkg-1.3.1 is forward compatible and can build, install, run and erase today's CURRENT packages which are scheduled for openpkg-2.0.0 release. Alex, come on, disclose your secret: which package you're talking about? We are unbribable - but interested :-) -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: OpenPKG ver 2.0
On Tue, Jan 20, 2004, [EMAIL PROTECTED] wrote: I must search in previus OpenPKG emails. What I'm interested is a port from a KDE project (I gues) that within others should easyer smtp authentication. Kolab? -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: How to build apache
On Tue, Dec 09, 2003, [EMAIL PROTECTED] wrote: As I ever used the prebuild apache package from the distro I used, and extra apache modules where offen separate packages (like mysql, php, perl), I'm not shure how to proceed with OpenPKG. looking at rpm -qpi apache-1.3.28-1.3.2.src.rpm it seema to me that all modules have to be build just when building apache. Is that so, or can I later add functionalitys to apache just ading a new module ? Although Michael explained a sophisticated workaround i want to point out that the OpenPKG way of doing it is to use static libraries which get embedded in the application at compile time. If you want to change an option, you need to rebuild. I don't want to go into deeper details because we will end up in a general static vs. shared library discussion. Maybe http://www.openpkg.org/faq.html#no-shlib in the FAQ will help you understanding the philosophy. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Why most packages default to PAM=NO
On Mon, Dec 08, 2003, [EMAIL PROTECTED] wrote: Can I live without PAM ? I need to implement a server with common web services (http with apache, ftp with pureftp, mail with Courier and Postfix, dns with bind) that I plan to administrat with ISPman that mantains an LDAP database for all setings and accounts. I whant every service to authenticate with users_email against the LDAP database, [...] replacing mod_auth_ldap by mod_auth_pam sounds promising. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: LDAP and SASL (chicken and egg)
On Mon, Dec 08, 2003, [EMAIL PROTECTED] wrote: I whant to enable sasl in OpenLDAP, that required me to install sasl. This in turn have an option to enable LDAP, but if set, it requires OpenLDAP to be installed. How should I proceed ? Do I need to install OpenLDAP without sasl to be able to compile sasl --with_ldap, and then recompile OpenLDAP --with_sasl ? The two options are mutually exclusive. Building openldap with_sasl means that OpenLDAP can use SASL mechanisms for authentication. Building sasl with_ldap means that SASL can use (Open)LDAP as password backend store. It is not possible to authenticate to the backend store using a mechanism that pulls out the password from that backend store :-) -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Mantaining OpenPKG updates
On Fri, Dec 05, 2003, [EMAIL PROTECTED] wrote: How can I proceed do be noticed of updates [...] Alex, you'll find information about OpenPKG security issues on a dedicated web page [1]. That page also explains on which mailing lists security advisories are posted and how to subscribe to the [EMAIL PROTECTED] list. [1] http://www.openpkg.org/security.html -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: installing sudo without installing MTA
On Fri, Nov 14, 2003, F. Even wrote: On 11/14/03 2:02 AM, Ralf S. Engelschall [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2003, F. Even wrote: Sorry that our documentation still lacks those details. [...] Is there anything I can do while using 1.3? It is a common practice to use a release version of OpenPKG for most of the packages and make an exception to use CURRENT packages where later vendor apps are needed. It is possible to mix and match OpenPKG branches up to a point where they become incompatible. The reason we do not promote this loudly is that it is very hard to describe the point of incompatiblity in a general fashion. Some of the critical points are macros being used in the spec files which need to be supplied by the bootstrap, same for shell functions in the rc files. Regarding spec macros and rc functions the situation is that openpkg-1.3.1-1.3.1 was upgraded to supply those introduced post-1.3.0 which are used in CURRENT (as of today :-) and probably in openpkg-2.0.0 when it becomes available. In the history of OpenPKG this is a unique issue of forward compatiblity. The more general approach is to stay with the release packages and upgrade the bootstrap to CURRENT where the bootstrap's age is somewhere between the release of the packages and the next release or CURRENT is next doesn't exist yet. OpenPKG bootstrap is always backward compatible with it's predecessor. Sometimes even with older ancestors, but no warranty. I'm talking about source compatiblity here. It is possible - and between OpenPKG 1.3 and 2.0 (aka CURRENT as of today) very likely - that binary packages are incompatible. You might need rebuilding and existing application from source in case you'll want to reinstall it. Another critical point are features in the fsl config require a later release of fsl, too. Because OSSP fsl development is driven by OpenPKG it is currently the only package where we introduce vendor updates in OpenPKG STABLE and SOLID branches, so you are safe with the latest UPD. You'll know when you need updating fsl when any UPD package requires so - build/install will tell you. In short, upgrade bootstrap to openpkg-1.3.1-1.3.1 and use postfix-2.0.16-20031028 or later. You must convince a RELEASE rpm to accept CURRENT package by adding --nodeps to the building and installation command lines. Are there any instructions for creating a virtual RPM with 1.3? Only the FAQ [1]. The wholly magic is Provides: MTA ...or will the import package work on 1.3? Untested, but it should. If it doesn't, tell me and i'll fix. [1] http://www.openpkg.org/faq.html#package-type -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
openpkg-import (Was: Re: Pine dependencies)
On Fri, Oct 03, 2003, Ralf S. Engelschall wrote: On Fri, Oct 03, 2003, Dennis McRitchie wrote: [...] I see your point, But as I explain in another message, here at the University, we need to have mail clients such as pine default to pointing to the standard OS sendmail (/usr/sbin/sendmail on RedHat and /usr/lib/sendmail on Solaris). So in my new rpm, I have a new option, which if enabled, allows pine to point to the system standard sendmail and removes the MTA dependency. [...] See my reply on the Pine message: the best solution IMHO is to write your own MTA package containing a symlink to your OS sendmail instead of hacking out the MTA dependency in each OpenPKG package. Triggered by this tread, Bill's and Dennis' input today we created a openpkg-import package which does exactly that: makes selected Operating System functionality available inside a OpenPKG instance. See http://cvs.openpkg.org/rlog?f=openpkg-src/openpkg-import/openpkg-import.spec $ /cw/bin/rpm --rebuild openpkg-import-* --define 'with_mta yes' $ /cw/bin/rpm --rebuild openpkg-import-* --define 'with_mta /my/favorite/sendmail' We prefer generic approaches, so this solution is not limited to MTA. If you find another operating system functionality we should have importable through that mechanism, please tell us. As a sidenode i want to mention that the name of this package was chosen carefully. We see a possibility to create a openpkg-export package some day which does the reverse: makes selected OpenPKG functionality available outside a OpenPKG instance. As far as i remember, Bill told me he created a OS (SuSE RPM) package which links to OpenPKG's sendmail executable. But that's another story. -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
sudo dependencies [Was: Re: Pine dependencies]
On Wed, Oct 01, 2003, Bill Campbell wrote:
On Wed, Oct 01, 2003, Steffen Weinreich wrote:
--On Mittwoch, Oktober 01, 2003 13:28:14 -0400 Dennis McRitchie
[EMAIL PROTECTED] wrote:
...
2) MTA
I assume that this is referring to a Mail Transport Agent. [...]
MTA is a virtual package [...]
This brings up a topic I've been meaning to address for a while.
The MTA package gets in the way when bootstrapping OpenPKG if one wants to
do the build as a non-root user using ``sudo'' since ``sudo'' depends on
MTA. [...]
Bill,
i understand this problem.
It is annoying to have the MTA requirement because the default
configuration of sudo does not even make use of the MTA. Also, the build
time decision whether to use an MTA or not is not enforced by sudo as it
can be configured in the sudoers file at any time. So we decided to drop
this requirement entirely, see http://cvs.openpkg.org/chngview?cn=12561.
For CURRENT, this means that the sendmail program is now hardcoded to
[/usr]/bin/true in order not to break sudo functionality. Those who want
to send mail need to configure mailerpath in the sudoers(5) file and
can no longer depend on the buildtime configuration. A small price to
pay, i think.
As soon as time permits, we'll try to further reduce sudo's indirect
requirements by removing the gcc dependency from fsl. In the meantime
you can bootstrap with_fsl=no and add it later if you wish.
Unless i hear complaints i'll MFC similar behavior into a sudo...-1.3.x
upgrade package next week. Countrary to CURRENT, the RELEASE update
should behave as much like the original version as possible. Maybe i
have to retain the execution of %{l_prefix}/sbin/sendmail and include a
[/usr]/bin/true binary called sendmail as a ghost file in case someone
really has MTA omitted. I have to think about that.
--
[EMAIL PROTECTED], Cable Wireless
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Subject: [OpenPKG-SA-2003.044] OpenPKG Security Advisory (openssl)
On Wed, Oct 01, 2003, Matthias Kurz wrote:
On Tue, Sep 30, 2003 at 03:45:23PM -0400, Dennis McRitchie wrote:
Hi,
What is the recommended way to reinstall the same package [...]
rpm -e openldap.
rpm -Uvh openldap.
Please note that, beginning with OpenPKG v1.3, -e (erase) will remove
default (not created) data, logs (!), pidfiles and run information
from the %{l_prefix}/var/%{name}/ directory.
1) Is there a better way?
I would prefer -Uvh --force instead. According to my experience, this
might tamper with your configuration, so check this afterwards.
I have another problem. I use some machines as masters, where the
software is build from sources. Then the generated binary packages
are installed on other machines.
I upgraded the machines that build from sources with
openpkg build -i -g -u openssl | sh
For standalone machines and masters as you describe them, a openpkg
build -Ua should be sufficent. I tried it on some instances and the
results looked fine. It even detected packages which used openssl due to
a conditional with_xxx option. As the generated script uses --force,
don't forget to check the configuration.
Being a little paranoid i also executed
$ for i in `/cw/bin/rpm -q --whatrequires openssl`; do \
/cw/bin/rpm -qi $i | grep Build Time; \
done
and checked if all eventually installed packages that directly depend on
openssl have been built recently. Needless to say, the last action is
always to test the final results.
But when i try this with binary packages
openpkg build -p platform
-r ftp://bla/.../RPM/PKG
-f ftp://bla/.../RPM/PKG/00INDEX.rdf.bz2
-i -g -u
I get
FATAL: cannot find source for 'openssl'
If your command listing above is complete it looks like you forgot to
create a new index.
--
[EMAIL PROTECTED], Cable Wireless
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: openssh 3.7.1 patched or not?
On Wed, Sep 17, 2003, Tom Brown wrote: why does the tarball for openssh-3.7p1.tar.gz have [...] when the advisory http://www.openssh.com/txt/buffer.adv [...] it's like 3.7.1 doesn't have all the changes in it?! If I'm right, and others have missed this, there may be a lot of folks with a false sense of security. Tom, not all others missed this. See OpenPKG Security Advisory http://www.openpkg.org/security/OpenPKG-SA-2003.040-openssh.html check the CVS timeline at http://cvs.openpkg.org/rlog?f=openpkg-src/openssh/openssh.spec and see the associated checkins referenced below. It's worth looking at the comments in the patches. http://cvs.openpkg.org/chngview?cn=12266 http://cvs.openpkg.org/chngview?cn=12268 upgrading package: openssh 3.7p1 - 3.7.1p1 add more bugfix patches from Solar Designer led to openssh-3.7.1p1-20030917 http://cvs.openpkg.org/chngview?cn=12270 apply buffer.adv V2 patch plus similar extra ones led to openssh-3.6.1p2-1.3.2 http://cvs.openpkg.org/chngview?cn=12272 apply buffer.adv V2 patch plus similar extra ones led to openssh-3.5p1-1.2.4 The OpenPKG-SA-2003.040-openssh was written with all issues but only the number CAN-2003-0693 known. Now we know more details. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0693 Original OpenSSH buffer handling problem, fixed in OpenSSH 3.7 http://marc.theaimsgroup.com/?l=openbsd-miscm=106371592604940 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0695 Updates to the OpenSSH buffer handling problem, fixed in OpenSSH 3.7.1 http://marc.theaimsgroup.com/?l=openbsd-security-announcem=106375582924840 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0682 Additional updates to OpenSSH by Solar Designer -- [EMAIL PROTECTED], Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Compiling newer .src.rpm under openpkg 1.2
On Mon, Aug 04, 2003, Vinod Kutty wrote:
I have an openpkg 1.2 install for which I'd like to compile imapd. There
isn't one readily packaged for 1.2, so I tried rebuilding the 1.3 src.rpm
(actually, I tried 20030731 first).
[...]
's;\(@[EMAIL PROTECTED]);/opt/opkg/1.2/RPM/TMP/imapd-2.1.14-root\1;g' '%{l_value'
[...]
Vinod!
The %{l_value ...} macro is new to OpenPKG v1.3. Many packages use it
and none of them can work with a v1.2 bootstrap. Other incompatiblities
would have caught you later, like the new -o option in rc's %status
section which also first appeared in OpenPKG v1.3. So you have to
upgrade the bootstrap to OpenPKG v1.3 first, please. This shouldn't
cause other problems as we tried to make the bootstrap backwards
compatible. But we cannot guarantee. Using rc for starting and stopping
daemons might give little different output and return codes which could
become relevant if you parse the output programmatically, otherwise it's
look'n'feel only. Good luck!
PS: don't forget to have a look at the
http://cvs.openpkg.org/openpkg-re/upgrade.txt file first.
--
[EMAIL PROTECTED]
Development Team, Operations Northern Europe, Cable Wireless
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: trouble forwarding fsl to syslog
On Wed, Apr 02, 2003, Martin Andrews wrote:
Dear Martin,
Finally working with fsl again. fsl-l2tool helped some, but a logger
type tool that actually read the fsl config would be great. [...]
I put this good idea on the wishlist.
Still
struggled with the fsl.postfix configuration. Syntax or other errors in
the fsl.postfix file caused postfix to dump core. Ug. Finally found that
this works: [...]
Skipping the target=remote would cause a core dump. Shouldn't that be
the default (only allowed) value? More importantly, moving the
target=remote attribute also causes bus errors - any idea why: [...]
The two examples you posted were identical (i assume by accident) and
they do not work. Here is a working configuration:
##
## fsl.postfix -- OSSP fsl configuration for Postfix
##
ident (postfix/.+)/.+ q{
prefix(
prefix=%b %d %H:%M:%S %N %L $1[%P]:
)
- {
debug: syslog(
facility=mail,
ident=postfix,
remotehost=127.0.0.1,
remoteport=514,
target=remote
)
}
};
As i explained in a previous posting, order of the parameters within the
syslog channel is important. This is a known issue (we) the OSSP l2 team
has to fix eventually. There is no default for the target option, it
must be set either local or remote.
--
[EMAIL PROTECTED]
Development Team, Operations Northern Europe, Cable Wireless
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: trouble forwarding fsl to syslog
On Thu, Apr 03, 2003, [EMAIL PROTECTED] wrote: On Wed, 2 Apr 2003, Martin Andrews wrote: struggled with the fsl.postfix configuration. Syntax or other errors in the fsl.postfix file caused postfix to dump core. Ug. [...] The fact that changes in the fsl or errors in configuring lead to core dumps lets me doubt if fsl is a good approach to the problem. In general I had several reports of people having problems with fsl which have been hard to track down. E.g. a program crashes because the log file is not writable etc. Besides my statements below regarding kolab disable fsl i want you to know that i was not able to crash postfix with syntatically or logically wrong fsl configs. I used postfix-2.0.2-1.2.1 with fsl-1.0.8-1.2.2 for testing. If you use these or later versions and find a configuration which crashes please tell me about it. Make sure you rebuild applications like postfix after an fsl upgrade - it's statically linked and won't change until after rebuild and reinstall the application. Additionally because of the static nature of OpenPKG it is not so easy to track down. It is as easy to find out if a program uses fsl and which version, even in a static configuration - see http://www.ossp.org/pkg/lib/fsl/faq.html#static-fsl In the kolab project we therefor decided to disable fsl everywhere. We are aware of this and i have an item on by TODO list to - check that really all packages using syslog(3) become fsl enabled - every use of fsl becomes an option which defaults to yes So in the near future you could easily inhibit fsl without having to hack every spec file. This decision was primarily driven by kolab. However, we still believe in fsl, even the current incarnation, and continue to support it. We are currently designing a major improvment of the underlying OSSP l2 library. This library is much more sophisticated than syslog(3) and the tradeoff is that the more complex code could more easily fail. This won't change because it can't. But we're working on a asynchronous channel which dedicates most of the logging to a different process, so crashes won't touch the main program anymore. If this work has been completed, fsl will inherit those improvments. It is our hope that kolab will finally come back on the fsl track in the future. We need the feedback of the community to improve the code. In general people are not used to crashes due to a non working logging setup. Taditionally if logging was not possible for whatever reason programs did continue to work. Agree, and that's what (we) the OSSP l2 team are working on. Thanks to this thread i improved and created - http://www.ossp.org/pkg/lib/fsl/faq.html#syslog-fsl - http://www.ossp.org/pkg/lib/fsl/faq.html#static-fsl Thank you for your feedback. -- [EMAIL PROTECTED] Development Team, Operations Northern Europe, Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: trouble forwarding fsl to syslog
Martin,
here are examples that i have tested to work successfully.
Verify syslog.conf was prepared. The syslog.conf(5) wants to see tabs
not spaces, i marked the output manually to make that clear.
$ grep mail.info /etc/syslog.conf
mail.info\t\t\t/var/log/maillog
Check if syslog is usable using standard tool.
$ logger -p mail.info from logger
Check if l2 can use syslog locally.
$ echo from l2, loc | fsl-l2tool 'syslog(facility=mail, ident=info,
target=local)'
Check if l2 can use syslog remotly. Make sure syslogd accepts network
connections, see it's -s option for syslogd(8) on FreeBSD, -r option for
syslogd(8) on Linux or -t for syslogd(1M) on Solaris. Also note that the
l2spec requires a certain order of the remotehost, remoteport an target
keywords, see http://cvs.ossp.org/chngview?cn=3313.
$ echo from l2, net | fsl-l2tool 'syslog(facility=mail, ident=info,
remotehost=127.0.0.1, remoteport=514, target=remote)'
Now create a fsl config entry. This one is for openssh.
##
## fsl.openssh -- OSSP fsl configuration for openssh
##
ident (ssh(d|-.+)?|scp|sftp(-server)?)/.+ q{
prefix(
prefix=%b %d %H:%M:%S %N %L $1[%P]:
)
- {
debug: file(
path=/usr/opkg/var/openssh/sshd.log,
append=1, perm=0644
);
debug: syslog(
facility=mail, ident=info,
remotehost=127.0.0.1, remoteport=514, target=remote
)
}
};
#Note: do not put HASH comments inside a l2spec
--
[EMAIL PROTECTED]
Development Team, Operations Northern Europe, Cable Wireless
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: trouble forwarding fsl to syslog
On Wed, Mar 19, 2003, Thomas Lotterer wrote: I also want to point out that the OSSP l2 library comes with a nifty command line l2tool which allows a user to quickly try a l2spec. This is half the way towards fsl. Unfortunately the l2tool is not installed along OpenPKG fsl so you either have to hack the fsl.spec (item for my personal TODO list) [...] OK, fsl now installes the tool. To avoid naming conflicts with the l2 package the binary is installed as fsl-l2tool. ftp://ftp.openpkg.org/current/SRC/fsl-1.0.8-20030320.src.rpm ftp://ftp.openpkg.org/release/1.2/UPD/fsl-1.0.8-1.2.2.src.rpm ftp://ftp.openpkg.org/release/1.1/UPD/fsl-1.0.8-1.1.2.src.rpm Quick and dirty example: $ echo foo | /cw/bin/fsl-l2tool \ 'debug: prefix ( prefix=[%b %d %H:%M:%S] %L [%P] ) - fd(fd=1)' [Mar 10 17:06:01] info [12726]foo -- [EMAIL PROTECTED] Development Team, Operations Northern Europe, Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
enviroment for building binary packages (Was: Re: dhcpd update does not rebuild on sol9)
On Thu, Feb 27, 2003, Ingo T. Storm wrote: BTW: SUNWhea, SUNWarc, SUNWtoo, SUNWlibm is what you need on top of a SUNWreq install in order to be able to be able to compile apache. But I guess they will be required for almost any compile at all. Ingo, to get all OpenPKG packages up'n'running you usually need some additional vendor packages first. We've carefully documented the ones we used to make our efforts most reproducable. The 00README file located in the BIN directory of every release lists the envirment used to produce the binaries, i.e. for OpenPKG v1.2 have a look at ftp://ftp.openpkg.org/release/1.2/BIN/00README It lists that we started Solaris 9 with entire distribution. It is obvious that developers and package builders need many tools and system libraries which do not come with a bare bone system so sometimes a lot of vendor packages have to be installed to make OpenPKG - and any additional software - working. This is especially true for Solaris which does not even come with a compiler. We try hard to make OpenPKG as independent as possible from the underlying OS but in the end OpenPKG is about packaging and not about changing world order (at least most of the time :-) -- [EMAIL PROTECTED] Development Team, Operations Northern Europe, Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: dhcpd update does not rebuild on sol9
On Fri, Feb 21, 2003, Ingo T. Storm wrote: short version: When rebuilding dhpd-xxx-1.2.1 on Solaris 9, make install expects /usr/ucb/install which is not there. I this a bug or am I not meeting the minimum requirements? [...] Since all my systems are rather minimal solaris installs, /usr/ucb/install from SUNWscpu is not there. Should I add that to my private minimum install for OpenPKG or is this a bug? Ingo, thanks for reporting that incident. I tracked down the issue down to the fact that we had the Source Compatibility, (Usr) (SUNWscpu) installed when we built the package. So we had /usr/ucb/install available and didn't notice the problem. It's not our intention to force you having SUNWscpu installed just to provide a install. However, installing the SUNWscpu package is the the obvious workaround for the affected packages, namely OPENPKG_CURRENT = dhcpd-3.0.1rc11-20030219 OPENPKG_1_STABLE = dhcpd-3.0.1rc11-1.20030219 OPENPKG_1_2_SOLID = dhcpd-3.0.1rc11-1.2.1 OPENPKG_1_1_SOLID = dhcpd-3.0.1rc9-1.1.2 The dependency to any vendor install has been removed and corrected packages are available for download. OPENPKG_CURRENT = dhcpd-3.0.1rc11-20030227 http://cvs.openpkg.org/chngview?cn=7740 ftp://ftp.openpkg.org/current/SRC/dhcpd-3.0.1rc11-20030227.src.rpm OPENPKG_1_STABLE = dhcpd-3.0.1rc11-1.20030227 http://cvs.openpkg.org/chngview?cn=7741 no ftp download available OPENPKG_1_2_SOLID = dhcpd-3.0.1rc11-1.2.2 http://cvs.openpkg.org/chngview?cn=7745 ftp://ftp.openpkg.org/release/1.2/UPD/dhcpd-3.0.1rc11-1.2.2.src.rpm OPENPKG_1_1_SOLID = dhcpd-3.0.1rc9-1.1.3 http://cvs.openpkg.org/chngview?cn=7747 ftp://ftp.openpkg.org/release/1.1/UPD/dhcpd-3.0.1rc9-1.1.3.src.rpm -- [EMAIL PROTECTED] Development Team, Operations Northern Europe, Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: perl requires gcc at runtime?
On Tue, Feb 25, 2003, Ralf S. Engelschall wrote: On Tue, Feb 25, 2003, Andrews, Martin wrote: I notices that gcc is getting installed on all my machines because perl (perl-5.8.0-1.2.0) has gcc as a runtime dependency. Is that right? I've put this into the FAQ. http://www.openpkg.org/faq.html#perl-gcc -- [EMAIL PROTECTED] Development Team, Operations Northern Europe, Cable Wireless __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Naming conventions
On Tue, Feb 18, 2003, Vinod Kutty wrote: Just looking for suggestions on: 1. Naming the root dir of an openpkg installation? Re Vinod, i already tried some variants in the past and here's my current personal proposal. It's all based around the factors - OpenPKG's location id that makes it into the filename of binary RPMs - my lazyness when typing path names in bash and - availability (!downtime) of a project's software environment. If the installation path is directly under the root, the location id is build from the first letters of this pathname. Otherwise if the installation path involves subdirectories it is build by concatenating the first letter of the subdirectory names along the path. Anyway, the location id is cut off after three characters max. This enforces uniqness within the first three letters in flat root instances or the first letter of the first three directory names in hierarchical instances. 1st character I install the OS and try to stick with the defauls wherever possible. The rule is that defaults don't have to be documented :-) In addition to the default OS filesytem layout, a large working disk space makes it into a separate filesystem which is mounted to a very short, usually one-letter, path. This can be networked filesystem. Example: /c 2nd charcater Every project get's a name and this makes up the directory name. The first letter should be unique across projects, guess why ... The project directory holds the actual data in properly structured subdirectories and that structure is entirely depend on the project. This could be a document_root/ folder with HTML files and CGI scripts, a CVS checkout directory, sometimes it's only symlinks to other places in the system or network etc. Example: /c/development/ with /c/development/sources/ and /c/development/ftp/ and /c/development/www/ 3rd character Inside every project there is at least one directory dedicated to the software needed by the project. Of course, the software is managed by OpenPKG. The name of the instance is 1sw for the first, 2sw for the second attempt etc. Example: /c/development/1sw/ Gain in Bash I only have to type /c/d TAB 1 TAB to get to the correct OpenPKG path. Gain for Backup The wholly project data can be backed up by saving /c/development/. The configuration of the project software can be backed up by saving /c/development/[0-9]sw/etc/. Gain for OpenPKG location id The /c/development/1sw/ examples above lead to the OpenPKG location id -cd1- which is unique across the wholly deployment as long as all rules above have been taken into account. Gain for OpenPKG upgrades If the software required to run a project is easy and simple to maintain, it's availablilty is totally noncritical and the knowledge of the OpenPKG adminstrator is high than any upgrade of OpenPKG software just means upgrading the OpenPKG package(s) on the fly. However, if the behaviour of the upgrade cannot be easily determined or the presence of the project is critical it's time for a 2sw instance to be build and configured in parallel. It's easy to start configuration as it can be done by diffing between 1sw/etc/* and 2sw/etc/*. Both installations might point to the same real data through links or copies of the data can be used easily as well. Depending on the lessons learned when creating the 2sw hierarchy, the 1sw later needs to be upgraded or the 2sw can take over. The latter allows to go back if real live experience would require it. My past experience was that it is very helpful that OpenPKG supports running multiple similar, in fact identical up to the IP address, instances at the same time. I consider this a major underestimated opportunity for OpenPKG administrators. The same is true when it comes to finding the correct configuration files. They can always be found at a easily predetermined location. And finally this is also true for variable data like logfiles, which the fake syslog library forces to be written to a predetermind location as well. Regarding major upgrades, independent if they're major OpenPKG or major vendor upgrades, my structure described above supports both the adventurer and the reluctant administrator. I've successfully upgraded some typical tools-mail-web-cvs installations from OpenPKG v1.1 to v1.2 by just installing openpkg-tool from v1.2 into the existing v1.1 instance and let it go. A little hunt for *.rpmsave files and some manual tweaking and it was done. I would not recommend naming any hierarchy by it's OpenPKG version number unless the version itself is the goal of the game, i.e. when you're doing OpenPKG packaging and want to see whether your package (change) smoothly runs on different OpenPKG versions. The OpenPKG team has to do this when creating security advisories for a package or
Re: OpenSSH default config: Priv. Separation + Root Login
On Mon, Jan 27, 2003, Vinod Kutty wrote: Just a suggestion: Would it make sense to have the default, out-of-the-box config of openssh's sshd_config use these options: UsePrivilegeSeparation yes (current default = no) PermitRootLogin no (current default = yes) in order to make the default config a little more secure (whatever that means 8-) )? Currently, the openpkg 1.1.x and 1.2 packaging of openssh 3.4p1 and 3.5p1 use the above defaults in parentheses. The vanilla openssh appears to set UsePrivilegeSeparation yes. We tried using UsePrivilegeSeparation (see http://cvs.openpkg.org/chngview?cn=3611) when there was a strong urge improving OpenSSH in March and June 2002 (see http://www.openpkg.org/security/OpenPKG-SA-2002.002-openssh.html and http://www.openpkg.org/security/OpenPKG-SA-2002.005-openssh.html) However, we had to find out that this new feature was incompatible with compression on some and PAM on all platforms, so we reverted back to the old fashion way (see http://cvs.openpkg.org/chngview?cn=3718). You can easily find more details by having a look at the timeline of openssh.spec (see http://cvs.openpkg.org/rlog?f=openpkg-src/openssh/openssh.spec). When we did research on using that new feature we had to find out it breaks the OpenPKG design goal of supporting different UNIX flavours equally. I do not currently believe it's time for another try, but we'll watch that issue. Regarding PermitRootLogin you're right. The OpenPKG default comes from the fact that the origin of OpenPKG is a ISP environment where OpenSSH is usually installed for remotely manage machines and this is mostly done (or started and then su - cw :-) using the root account. If we change that default, we would have to manually do that configuration on every installation. However, it seems Ralf already made the decision to follow your suggestion. -- [EMAIL PROTECTED] Development Team, Application Services, Cable Wireless Deutschland GmbH __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Using compress/uncompress during bootstrap
On Tue, Jan 14, 2003, Ralf S. Engelschall wrote: On Mon, Jan 13, 2003, Bill Campbell wrote: [...] Does the *.src.sh script benefit much from compression? [...] Hmmm yes, indeed. You're right, it does not benefit much. [...] FAQ updated, see http://cvs.openpkg.org/chngview?cn=6627 -- [EMAIL PROTECTED] Development Team, Application Services, Cable Wireless Deutschland GmbH __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: patches for 1.1.0 to fix snprintf
On Thu, Nov 14, 2002, Ian Alexander wrote: Problem is related to not having vsnprintf/snprintf on host system (in my case, solaris 2.5.1). The first patch fixes this problem in rpm. You will also need to apply the second patch to the openpkg.spec. Hope this helps someone else out there. Dear Ian, Ralf and i discussed the inclusion of your patch into OpenPKG today. We decided not to include it. The use of sprintf(3) as a replacement for snprintf(3) has a high potential to cause buffer overflows, leading to program crashes and opening security issues. The price to support this outdated Solaris v2.5.1 is too high. Nevertheless, the patch basically works and i hope it will help you and probably others to use OpenPKG on affected platforms. -- [EMAIL PROTECTED] Development Team, Application Services, Cable Wireless Deutschland GmbH __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Help me please for installation......
Nicola Frosini wrote: Can anyone help me to install OpenPKG on a Linux Red-Hat 6.2 Thanks a lot ! Nicola What's the problem? I'm using OpenPKG successfully on RedHat 6.x Here're a list of versions i'm using: # uname -a Linux foo 2.2.12-32 #1 Mon Oct 25 19:26:01 EDT 1999 i586 unknown # /cw/bin/rpm -q openpkg openpkg-20020404-20020404 __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
