can openpkg realy help me
hi openpkg-users, after evaluation openpkg for some time my initial enthusiasm starts turning into light frustration, because each step i go further, new problems occur that throw me back two steps. with this email, i would like to explain to you, how i planed to use openpkg, and would be glad, if you could give me your opinion, if openpkg can really help me in making my job easier. it's a quite long email, but it takes some lines, so describe my expectations and problems. we are developing web applications, mostly based on software like java (j2ee), apache, db-servers, ldap-servers in various combinations and configurations. the task: since there are a lot of projects to handle we need shared development- and test-servers for our projects. i want to use openpkg to completely separate the projects on the machine. each project gets it's own openpkg instance. a central instance is used for some uncritical proxied general purpose-packages. there are two primary reasons for me to use openpkg this way: -easy handling of different versions of a package on one machine -easy switching on/off all components of an instance the latter is important, because we have only a limited number of active projects, that should get the machines resources, but a lot of sleeping-support-project, that should not get any resources, unless a client calls with a problem. then we need to be able to switch on the whole project very quickly and without interfering other running projects. a minor reason for using openpkg is, that although our development-servers are completely linux-based, the production-servers are sometimes sun-solaris machines. openpkg promises seemed to fit perfect for this job -- at first. in practice, i have the problem, that we have a lot of legacy-projects, sometimes with very old software-versions. and even in new projects, we often can't decide, which version of a specific package we have to use. so we must be able to build specific releases of the various packages, not only the one, distributed with the openpkg instance. maybe it would be possible to get source-rpm for older versions from the cvs, but is there a guarantee, that a source-rpm of openpkg 1.2 will run in an openpkg 2.2 instance? my first experience in building older apache versions from apaches src.tar.gz ends in coredumps. for me, it's difficult enough to build everything from source (not with openpkg- that runs smooth, but with regular source distributions). but if i have to expect additional problems because i'm using openpkg, this makes my world darker, not lighter. second: java-web application-environments doesn't seem to be a major focus of the openpkg-community. trying to build a really basic and common configuration with apache2, tomcat4 and mod_jk-connector with the current release didn't succeed. i wouldn't expect this, if more people out there were using openpkg for this kind of stuff. so, if this is my primary focus, i would have to dig deep into openpkg before being able to use it. third: this is just a minor issue, but it seems, that the concept of proxy-packages isn't used very much too. otherwise, maybe, since disk space is cheap, that's no critical problem, but for easy administration of often used packages, it would help prevent some boring work. i'm not shure, whether i did just miss the right way to use openpkg. but i didn't find one. so, what is your opinion? is it worth for me, to dig deeper into openpkg, because there's a light at the end of the tunnel. or do i expect things, that openpkg can't deliver (now)? don't get me wrong. openpkg has an impressing concept, and i'm sure, there are many environments, where it really solves problems. but i'm not sure, if does it for me. of course i know, that openpkg is open source and lives from get-and-give. and i would be glad to support the project on my way getting more experienced. but if i would have to get an openpkg-pro first, before being able to solve my basic tasks (like installing apache2-tomcat4-mod_jk), i prefer fiddling with my old problems instead of getting additional new ones. or maybe, the expected average openpkg user is higher qualified than me -- i'm no experienced rpm-administrator, building easily .spec-files and produce patches. till now it was sufficient for my job to get the necessary packages and find the right ./configure options. i'm looking forward reading your replies. thanks in advance, andi __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Can openpkg realy help me
On Thu, Oct 28, 2004, Andreas SCHMIDT wrote: the task: since there are a lot of projects to handle we need shared development- and test-servers for our projects. i want to use openpkg to completely separate the projects on the machine. each project gets it's own openpkg instance. a central instance is used for some uncritical proxied general purpose-packages. This is very similar to what I use OpenPKG for, and a basic OpenPKG requirement from early on in the project. I think in this case OpenPKG will make your work easier, and will probably outperform other packaging utilities. a minor reason for using openpkg is, that although our development-servers are completely linux-based, the production-servers are sometimes sun-solaris machines. With only two platforms to cover, OpenPKG only has a marginal advantage over other packaging utilities. in practice, i have the problem, that we have a lot of legacy-projects, sometimes with very old software-versions. and even in new projects, we often can't decide, which version of a specific package we have to use. so we must be able to build specific releases of the various packages, not only the one, distributed with the openpkg instance. maybe it would be possible to get source-rpm for older versions from the cvs, but is there a guarantee, that a source-rpm of openpkg 1.2 will run in an openpkg 2.2 instance? my first experience in building older apache versions from apaches src.tar.gz ends in coredumps. for me, it's difficult enough to build everything from source (not with openpkg- that runs smooth, but with regular source distributions). but if i have to expect additional problems because i'm using openpkg, this makes my world darker, not lighter. If using software older than 1 year is your main requirement, then OpenPKG's policy of supporting only the last two releases is a disadvantage. Here I recommend dpkg with two comments. First, you should limit your Linux platforms to Debian only and make all your own packages for the Solaris systems. Second, even the newest stable debian packages are often outdated, so you have to be happy with running relatively old software. second: java-web application-environments doesn't seem to be a major focus of the openpkg-community. trying to build a really basic and common configuration with apache2, tomcat4 and mod_jk-connector with the current release didn't succeed. i wouldn't expect this, if more people out there were using openpkg for this kind of stuff. so, if this is my primary focus, i would have to dig deep into openpkg before being able to use it. Those aren't all release packages, so OpenPKG does not meet this requirement. If you aren't willing to write or correct the packages yourself, then this could be a problem. Remember that if you find a SRPM (source RPM package) for any of the software you are missing, making an OpenPKG package out of it is relatively simple. so, what is your opinion? is it worth for me, to dig deeper into openpkg, because there's a light at the end of the tunnel. or do i expect things, that openpkg can't deliver (now)? There are other packaging utilities for you to consider, though I expect (from your work environment explanation) that you'll find them rather unsatisfying. But lets be optimistic, and spend an afternoon installing plain RPM or dpkg on Solaris. Then the next day try building packages from source on there. You won't be able to have more than one instance on the machine, and will be missing some other OpenPKG features. I'm not sure how far you'll get with this approach, but you'll be in a good position to make the right decision. Regards, Michael -- Michael Schloh von Bennewitz [EMAIL PROTECTED] Development Team, Operations Northern Europe Cable Wireless Telecommunications Services Tel +49-89-92699-227, Fax +49-89-92699-808 pgplyBIl9qUQw.pgp Description: PGP signature
Re: can openpkg realy help me
Hi, be possible to get source-rpm for older versions from the cvs, but is there a guarantee, that a source-rpm of openpkg 1.2 will run in an openpkg 2.2 instance? no. It will definitely fail, the openpkg bootstrap releases are not compatible. second: java-web application-environments doesn't seem to be a major focus of the openpkg-community. trying to build a really basic and common configuration with apache2, tomcat4 and mod_jk-connector with the current release didn't succeed. i wouldn't expect this, if more people out there were using openpkg for this kind of stuff. Lets say, apache2 isn't the major focus :) The goal should therefore be to package the tomcat adapter for apache2. For apache1 you just install the tomcat4-adapter (which is mod_webapp and optionally mod_jk). third: this is just a minor issue, but it seems, that the concept of proxy-packages isn't used very much too. Indeed. Usually it creates more problems than it solves. otherwise, maybe, since disk space is cheap, that's no critical problem, but for easy administration of often used packages, it would help prevent some boring work. Where do you see the boring work ? You need time to build the packages, but that's CPU time and not your time. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] A potential Snark may lurk in every tree. __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: can openpkg realy help me
On Thu, 2004-10-28 at 05:26, Andreas Schmidt wrote: hi openpkg-users, Hi. after evaluation openpkg for some time my initial enthusiasm starts turning into light frustration, because each step i go further, new problems occur that throw me back two steps. I had this phase in my learning process as well. I went back and forth between other potential packaging products but in the end I made it past this phase because I determined that the pros by far outweighed the cons. I think it's merely a matter of accepting how They (as in the openpkg folks here) develop and use OpenPKG themselves and not trying to mold it into something else that perhaps you're comfortable with at the moment. Instead learn to be comfortable with how OpenPKG functions and work with that. At least that was my learning experiences initially. with this email, i would like to explain to you, how i planed to use openpkg, and would be glad, if you could give me your opinion, if openpkg can really help me in making my job easier. it's a quite long email, but it takes some lines, so describe my expectations and problems. we are developing web applications, mostly based on software like java (j2ee), apache, db-servers, ldap-servers in various combinations and configurations. the task: since there are a lot of projects to handle we need shared development- and test-servers for our projects. i want to use openpkg to completely separate the projects on the machine. each project gets it's own openpkg instance. a central instance is used for some uncritical proxied general purpose-packages. It sounds more like you should just use UML. (http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO.html) there are two primary reasons for me to use openpkg this way: -easy handling of different versions of a package on one machine -easy switching on/off all components of an instance the latter is important, because we have only a limited number of active projects, that should get the machines resources, but a lot of sleeping-support-project, that should not get any resources, unless a client calls with a problem. then we need to be able to switch on the whole project very quickly and without interfering other running projects. a minor reason for using openpkg is, that although our development-servers are completely linux-based, the production-servers are sometimes sun-solaris machines. Hmmm. It can be dangerous to allow developers to do their development on a platform/architecture which is not identical to what exists in production. In general, there usually won't be problems, however it's still feasible and common in my experience for problems to occur. Just a side note. openpkg promises seemed to fit perfect for this job -- at first. in practice, i have the problem, that we have a lot of legacy-projects, sometimes with very old software-versions. and even in new projects, we often can't decide, which version of a specific package we have to use. so we must be able to build specific releases of the various packages, not only the one, distributed with the openpkg instance. maybe it would be possible to get source-rpm for older versions from the cvs, but is there a guarantee, that a source-rpm of openpkg 1.2 will run in an openpkg 2.2 instance? my first experience in building older apache versions from apaches src.tar.gz ends in coredumps. for me, it's difficult enough to build everything from source (not with openpkg- that runs smooth, but with regular source distributions). but if i have to expect additional problems because i'm using openpkg, this makes my world darker, not lighter. second: java-web application-environments doesn't seem to be a major focus of the openpkg-community. trying to build a really basic and common configuration with apache2, tomcat4 and mod_jk-connector with the current release didn't succeed. i wouldn't expect this, if more people out there were using openpkg for this kind of stuff. so, if this is my primary focus, i would have to dig deep into openpkg before being able to use it. It all comes down to learning how to build rpms, customize spec files and using the options. It's a lot of work in the forefront, but once you're done the efforts pay off greatly. The maintenance of the rpms is really simple. That is the ultimate reward or benefits for using OpenPKG. Lowing overall maintenance cost. third: this is just a minor issue, but it seems, that the concept of proxy-packages isn't used very much too. otherwise, maybe, since disk space is cheap, that's no critical problem, but for easy administration of often used packages, it would help prevent some boring work. i'm not shure, whether i did just miss the right way to use openpkg. but i didn't find one. so, what is your opinion? is it worth for me, to dig deeper into openpkg, because there's a light at the end of the tunnel. or do i
Re: Can openpkg realy help me
On Thu, 2004-10-28 at 07:45, Michael Schloh wrote: a minor reason for using openpkg is, that although our development-servers are completely linux-based, the production-servers are sometimes sun-solaris machines. With only two platforms to cover, OpenPKG only has a marginal advantage over other packaging utilities. Well, I don't know about that. It depends on how many servers you have as well. We only have Linux and Solaris in our environment but we have close to 100 servers and OpenPKG is extremely useful for us. It has cut down our maintenance cost by magnitudes already and we still haven't got it all fully automated in the fashion we want. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu Only those who attempt the absurd can achieve the impossible. signature.asc Description: This is a digitally signed message part
Re: Can openpkg realy help me
On Thu, Oct 28, 2004, David M. Fetter wrote: On Thu, 2004-10-28 at 07:45, Michael Schloh wrote: a minor reason for using openpkg is, that although our development-servers are completely linux-based, the production-servers are sometimes sun-solaris machines. With only two platforms to cover, OpenPKG only has a marginal advantage over other packaging utilities. Well, I don't know about that. It depends on how many servers you have as well. We only have Linux and Solaris in our environment but we have close to 100 servers and OpenPKG is extremely useful for us. It has cut down our maintenance cost by magnitudes already and we still haven't got it all fully automated in the fashion we want. Good point. My comment comes from a conservative point of view, in which the OpenPKG's advantages when administrating more than ten different platforms greatly outweighs those advantages when administrating only two. From a more progressive point of view you could argue that OpenPKG delivers big advantages even when administrating on a single platform (and still be correct). Regards, Michael -- Michael Schloh von Bennewitz [EMAIL PROTECTED] Development Team, Operations Northern Europe Cable Wireless Telecommunications Services Tel +49-89-92699-227, Fax +49-89-92699-808 pgpj39P7pWB0h.pgp Description: PGP signature
Re: can openpkg realy help me
On Thu, Oct 28, 2004, Andreas Schmidt wrote: [...] we are developing web applications, mostly based on software like java (j2ee), apache, db-servers, ldap-servers in various combinations and configurations. Well, right after mentioning things like Java and Apache2 it becomes immediately clear to me that OpenPKG will not solve your problems out-of-the-box ;-) Sorry for this, but during the last years, neither Java nor Apache2 were ever of any major importance to us (Java is not really Open Source and nasty to package because mainly a binary distribution which doesn't fit with OpenPKG's from-source approach and Apache2 is... well, Apache1 is sufficiently nasty and I know Apache1 well enough ;-). So, it is clear that those products are not as well packaged and tested as others. At least not until somebody helps out and polishes them. You also can see this by looking (openpkg rpm -qpi) at the Group RPM header of those packages: they are of class EVAL or maximum PLUS since a long time which means that they are not in the focus of one of the core OpenPKG developers. [...] a minor reason for using openpkg is, that although our development-servers are completely linux-based, the production-servers are sometimes sun-solaris machines. Minor reason? Ops, I'm surprised. At least most of the administrators I know of count the possibility to easily reproduce 1:1 a development environment on a production machine a _major_ reason. But ok, no offence here, everyone has its own priorities... [...] in practice, i have the problem, that we have a lot of legacy-projects, sometimes with very old software-versions. and even in new projects, we often can't decide, which version of a specific package we have to use. so we must be able to build specific releases of the various packages, not only the one, distributed with the openpkg instance. maybe it would be possible to get source-rpm for older versions from the cvs, but is there a guarantee, that a source-rpm of openpkg 1.2 will run in an openpkg 2.2 instance? No, but unfortunately this guarrantee you also will _not_ get from _any_ software distribution. It's a general problem in the software business. At least all Unix software distributions I know of allow you to mix releases only to some limited extend. And most of the time it is not really the fault of the distributions, but just a nasty side-effects of the fast and independently evolving vendor versions. You cannot expect e.g. to run an old Linux program without problems under the latest Linux kernel and GNU C library (and vice versa). Most of the time it will already fail to start because of incompatible ABIs and fail to recompile because of incompatible APIs. my first experience in building older apache versions from apaches src.tar.gz ends in coredumps. Yes, that's why software distributions create releases where all components fit together. Mixing software from different releases inherently fails, although for the really portable products it works to some extend. Unfortunately most products are not portable and self-adjustment enough. [...] second: java-web application-environments doesn't seem to be a major focus of the openpkg-community. trying to build a really basic and common configuration with apache2, tomcat4 and mod_jk-connector with the current release didn't succeed. i wouldn't expect this, if more people out there were using openpkg for this kind of stuff. so, if this is my primary focus, i would have to dig deep into openpkg before being able to use it. Yes, your ultimate problem is that you need a combination of two products where each of them already is not well packaged and tested. It is clear that this has to fail inherently. [...] so, what is your opinion? is it worth for me, to dig deeper into openpkg, because there's a light at the end of the tunnel. or do i expect things, that openpkg can't deliver (now)? [...] I think it is as simple as it can be for any type of technology: OpenPKG solves a bunch of problems and causes some others. Whether it is worth the effort for you depends on the balance. If OpenPKG currently makes you more problems than it helps you and you cannot afford helping out here to change this for your own near future, do not waste your time and forget OpenPKG immediately and go a different direction. If you are convinced that once you solved your current problems with OpenPKG it will help you _multiple_ times in the future, stay with us and help out. OpenPKG is a tool, nothing more. If it still doesn't help you solving the problem, either fix it or throw it away. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL
Re: Can openpkg realy help me
Good point. My comment comes from a conservative point of view, in which the OpenPKG's advantages when administrating more than ten different platforms greatly outweighs those advantages when administrating only two. From a more progressive point of view you could argue that OpenPKG delivers big advantages even when administrating on a single platform (and still be correct). Regards, Michael And let's not forget that platforms change. If today I am a redhat shop, but tomorrow management decides we are a suse shop, with all of my services in an OpenPKG sandbox, none of my processes and methodologies really change. Since converting most of my linux/solaris to OpenPKG, I often forget what the underlying OS is on the server I am working on. That in itself is a beautiful thing. :) Aaron __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: can openpkg realy help me
On Thu, 28 Oct 2004, Ralf S. Engelschall wrote: [...snip_all_java_apache2_mod_jk_tomcat4_stuff...] Trying to accomodate java stuff, try to learn how openpkg's specs look/work like and look at jpackage.org. There you will see how many requirements have to be met to allow tomcat4 to build/use and how many are required for apache2, not speaking of both together. The easiest path would be to accomodate first w/ rpm specs, after that w/ openpkg's specs, and modify the jpackage.org's specs to be openpkg compatible. Don't get me wrong, I don't want to tell you don't use openpkg, but java is not a usual package, not speaking of the dependencies to use tomcat4 w/ apache2. I have built java-1.4.2 (from source), tomcat5 and mod_jk2 w/ apache2, but haven't managed to use tomcat4. My experience is non-openpkg, it's native, where all the used libs are not semi shared due to the constrains of openpkg. In an openpkg env. I would try the newest versions, as: apache2, tomcat5, mod_jk2, else probably you will have much trouble w/ incompatibilities, non-working versions. Peter -- Peter S. Mazinger ps dot m at gmx dot net ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
