Re: Request for Assistance - Consulting Opportunity For Pay
On Saturday 29 December 2001 23:11, Mike Andrew wrote: double rant squared I rather get the impression you don't like the situation? 8-) Terence ___ Linux-users mailing list Archives, Digests, etc at http://linux.nf/mailman/listinfo/linux-users
Re: Request for Assistance - Consulting Opportunity For Pay
On Friday 28 December 2001 09:44 pm, you wrote: Hello: Since I have great respect for the opinions and knowledge of the individuals on these lists, I'm humbly asking for your help. I've got the following problem: Linux 2.4.13 system GCC 2.95.3 In an attempt to upgrade the gcc to 3.0.2 and such I've somehow managed to break it badly...I'm fairly sure its not gcc that broken but rather the libc and glibc stuff thats messed up. I've attempted to restore it but obviously I'm not getting it right. The system is 100% functional if you don't mind I can't compile anything from source...LOL Others will be able to help you get back to the status quo ante. Be advised, I've never heard of any good results using the gcc 3... compiler. I'm fairly sure that the compiler is indded broken, although you may have broken something else as well. Avoid gcc 3 like the plague - you've already experienced its benefits (ie none). Thanks, Collins ___ Linux-users mailing list Archives, Digests, etc at http://linux.nf/mailman/listinfo/linux-users
Re: Request for Assistance - Consulting Opportunity For Pay
On December 29, Collins Richey enlightened our ignorance thusly: Others will be able to help you get back to the status quo ante. Be advised, I've never heard of any good results using the gcc 3... compiler. I'm fairly sure that the compiler is indded broken, although you may have broken something else as well. Avoid gcc 3 like the plague - you've already experienced its benefits (ie none). I've used gcc 3.0.x without incident since it was released in June. The compiler is not broken. There are some problems with certain apps and libraries, but this has been the case with gcc for quite some time -- such as older version of the kernel and glibc relying on bugs in the compiler. In fact, I've heard reports of success *and* failure building the kernel with gcc 3.0.x. Please defined what indded [sic] broken means. There are more benefits to using gcc 3.0 than you realize -- I've been living with it for several months and, aside from known misfeatures, it is a better product than the 2.95 series: new preprocessor, better optimizations, more standards compliant, and so forth. As always, YMMV. Kurt -- James Joyce -- an essentially private man who wished his total indifference to public notice to be universally recognized. -- Tom Stoppard ___ Linux-users mailing list Archives, Digests, etc at http://linux.nf/mailman/listinfo/linux-users
Re: Request for Assistance - Consulting Opportunity For Pay
[Posted and emailed] On December 28, George Kasica enlightened our ignorance thusly: Hello: Since I have great respect for the opinions and knowledge of the individuals on these lists, I'm humbly asking for your help. I've got the following problem: Linux 2.4.13 system GCC 2.95.3 In an attempt to upgrade the gcc to 3.0.2 and such I've somehow managed to break it badly...I'm fairly sure its not gcc that broken but rather the libc and glibc stuff thats messed up. Please be more precise in your description of the problem. For example, what are you trying to do and what is going wrong? What distribution are you using? I've attempted to restore it but obviously I'm not getting it right. The system is 100% functional if you don't mind I can't compile anything from source...LOL What did you do to restore it? What is it? The original compiler? The problem is: I NEED to be able to do this in order to keep current with various packages (bind, apache, etc.). My question: I KNOW there is a way to recover and or reinstall the stuff in /lib /usr/local/lib and also the libc and glibc stuff to get this working. However, being a production box, I can't afford to mess this up and take the box down as I have paying customers that would be quite irritated by this turn of events (VBG). Ideally in this process I can get to the current revs of GCC and glibc, etc which is what started the problem in the first place. Using an rpm-based distribution would make this easier. What I'm asking is: Is there ANYONE out there that know how to do this and would be willing to do the job FOR PAY in the very near future? REBUILDING THE BOX FROM SCRATCH IS NOT AN OPTION. Though I do do a full tape backup nightly, the time between the attempts and noticing they broke something is beyond the length of tapes I have here... Contact me off list if you like ([EMAIL PROTECTED]) and I'll be glad to help. Kurt -- For your penance, say five Hail Marys and one loud BLAH! ___ Linux-users mailing list Archives, Digests, etc at http://linux.nf/mailman/listinfo/linux-users
Re: Request for Assistance - Consulting Opportunity For Pay
Sorry for cross posting, but maybe this will be interesting on both. Does anyone know of any lists that discuss reliability and disaster recovery? I have some ideas below, but they are from my experience only. George Kasica wrote: [...] What I'm asking is: Is there ANYONE out there that know how to do this and would be willing to do the job FOR PAY in the very near future? REBUILDING THE BOX FROM SCRATCH IS NOT AN OPTION. Though I do do a full tape backup nightly, the time between the attempts and noticing they broke something is beyond the length of tapes I have here... It would be cheaper for you, I think, to fix it yourself. If you can't have the box down, get another one and build a system on it (you can start with backup tapes if you think that's easier). Copy over all your production stuff and test it out. When it's ready, stick it into the network and pull the old one. The switch should be done during a low traffic period, and if you're careful about how you do it (and how your network is arranged), your customers won't notice. If you don't have time to do this yourself, then I guess you're into paying someone. But I would not try to fix the problem in place. gcc is one thing but when you mess with glibc you risk breaking what's running and your customers will notice. I don't think I'd trust even an expert to do this, since he's unlikely to know all the details of your system. Here are some suggestions to avoid this problem in the future: You should have a test box in addition to your production box. They should be identical hardware and software (you probably don't need gcc or other development tools on the production box, though). When you need to upgrade a package, build it on the test box in such a way that you get a tar file - there's usually some sort of distribution make target for this sort of thing. Install the package by untarring, both on the test box and the production box. To be even safer, get yourself a development box and do the building there. That way the process you use on the test box and the production box will be identical, and you'll know what to expect. Test out your new package *thouroughly* before you put it on the production box. You have to make sure that config and data files get updated at the same time. Ideally, you'll be able to back out changes in your test system and start over so that if there's a problem you can fix it and redo the whole process. Your upgrade procedure needs to be straightforward so you don't mess it up on the production system. Bigger packages, like glibc, will need more testing than something like apache. But you should only upgrade the base system when it's necessary to support a new package you need. This system should be stable, not bleeding edge. If your customers are changing their data frequently, then backing out a package by restoring from tape becomes problematic. You should think about isolating all your application packages in their own directory trees so they can be removed and reinstalled easily. You should save each build you do, and have a way to identify which configurations you used with which build (a version control system can be very good for this). You might also consider backing up data separately from the applications, so you can downgrade an application without losing customer data. Finally, you should expect your production box to be blown into tiny pieces some day. Pretend that it happened and do what you'd need to recover from it. That will test your backups and documentation to make sure that it all works. It will also give you some idea of how long you'll be down, worst case. Maybe this is overly idealistic, to expect you to know that you can handle disasters. None of the providers I know does this (and they aren't small businesses). HTH, Dave ___ Linux-users mailing list Archives, Digests, etc at http://linux.nf/mailman/listinfo/linux-users
Re: Request for Assistance - Consulting Opportunity For Pay
On Saturday 29 December 2001 08:39 am, you wrote: On December 29, Collins Richey enlightened our ignorance thusly: Others will be able to help you get back to the status quo ante. Be advised, I've never heard of any good results using the gcc 3... compiler. I'm fairly sure that the compiler is indded broken, although you may have broken something else as well. Avoid gcc 3 like the plague - you've already experienced its benefits (ie none). I've used gcc 3.0.x without incident since it was released in June. The compiler is not broken. There are some problems with certain apps and libraries, but this has been the case with gcc for quite some time -- such as older version of the kernel and glibc relying on bugs in the compiler. In fact, I've heard reports of success *and* failure building the kernel with gcc 3.0.x. Please defined what indded [sic] broken means. There are more benefits to using gcc 3.0 than you realize -- I've been living with it for several months and, aside from known misfeatures, it is a better product than the 2.95 series: new preprocessor, better optimizations, more standards compliant, and so forth. Kurt, thanks for correcting me. I don't pretend to be an expert in these matters, and I respect your superior knowledge, but I keep reading that various products, including the kernel, don't build well with gcc 3. I seem to remember advice from the kernel developers (Linux or ???) not to use gcc 3. I've heard rumblings that kde doesn't wok either, although I've not tried that. I have an older K6/II which doesn't benifit very much from optimizations. When kernel 2.4.17 (-o2 -march=i586, about as plain vanilla as you can get) fails in one of the driver compiles for the isdn series with a message saying the compiler has generated an invalid instruction, I consider it broken. The other possibility is that the kernel is broken; wouldn't be the first time. I'm sure that sometime in the next few months most of the subleties between gcc and glibc and most of the common products will be worked out and that will be the new standard. In the mean time, it's still too experimental for my tastes. rant It would surely be nice if the compiler and library folks could make progress without breaking old things. I still remember (not too fondly) all the havoc that the current glibc generated when it was new. /rant Thanks, Collins ___ Linux-users mailing list Archives, Digests, etc at http://linux.nf/mailman/listinfo/linux-users
Re: Request for Assistance - Consulting Opportunity For Pay
I really have to agree with Dave on this. I can think of alot of ways to recover from this, and unless you have money to burn, you really don't need a consultant to help you do it. But if you still feel differently, and haven't found anyone for the job, i'll gladly take up the flag. Contact me off list for that. I will make an additional note here. If this is such a critical production server, then why were you making changes when you lacked recent backups? Or possibly more importantly, why were you making changes when you weren't 100% certain what you were doing? Whenever i'm making changes that I have the slightest suspicion may break the box, i always do a dry run on a test box first. glibc gcc are prolly the worst offenders, as once you break either, you may be toast. --- Dave Anselmi [EMAIL PROTECTED] wrote: Sorry for cross posting, but maybe this will be interesting on both. Does anyone know of any lists that discuss reliability and disaster recovery? I have some ideas below, but they are from my experience only. George Kasica wrote: [...] What I'm asking is: Is there ANYONE out there that know how to do this and would be willing to do the job FOR PAY in the very near future? REBUILDING THE BOX FROM SCRATCH IS NOT AN OPTION. Though I do do a full tape backup nightly, the time between the attempts and noticing they broke something is beyond the length of tapes I have here... It would be cheaper for you, I think, to fix it yourself. If you can't have the box down, get another one and build a system on it (you can start with backup tapes if you think that's easier). Copy over all your production stuff and test it out. When it's ready, stick it into the network and pull the old one. The switch should be done during a low traffic period, and if you're careful about how you do it (and how your network is arranged), your customers won't notice. If you don't have time to do this yourself, then I guess you're into paying someone. But I would not try to fix the problem in place. gcc is one thing but when you mess with glibc you risk breaking what's running and your customers will notice. I don't think I'd trust even an expert to do this, since he's unlikely to know all the details of your system. Here are some suggestions to avoid this problem in the future: You should have a test box in addition to your production box. They should be identical hardware and software (you probably don't need gcc or other development tools on the production box, though). When you need to upgrade a package, build it on the test box in such a way that you get a tar file - there's usually some sort of distribution make target for this sort of thing. Install the package by untarring, both on the test box and the production box. To be even safer, get yourself a development box and do the building there. That way the process you use on the test box and the production box will be identical, and you'll know what to expect. Test out your new package *thouroughly* before you put it on the production box. You have to make sure that config and data files get updated at the same time. Ideally, you'll be able to back out changes in your test system and start over so that if there's a problem you can fix it and redo the whole process. Your upgrade procedure needs to be straightforward so you don't mess it up on the production system. Bigger packages, like glibc, will need more testing than something like apache. But you should only upgrade the base system when it's necessary to support a new package you need. This system should be stable, not bleeding edge. = Lonni J. Friedman [EMAIL PROTECTED] Linux Step-by-step help: http://netllama.ipfox.com . __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com ___ Linux-users mailing list Archives, Digests, etc at http://linux.nf/mailman/listinfo/linux-users
Re: Request for Assistance - Consulting Opportunity For Pay
On Sun, 30 Dec 2001 05:12, Collins Richey wrote: rant It would surely be nice if the compiler and library folks could make progress without breaking old things. I still remember (not too fondly) all the havoc that the current glibc generated when it was new. /rant double rant squared THE problem with glibc is that is not a General Library of C at all but a truly confused mish-mash of kernel only specifics and userland generics. A *general* C library is just that. It contains agnostic code such as printf(), strcpy() and others, uses standard headers such as ctype.h . It does not have stupidites in it for kernel locking semaphores, and equally ridiculous and constantly changing header files. If anyone can ever explain to me what the kernel only printk() statement is doing in a *general* library, I'll learn Visual Basic as a punishment. The idea behind a *general* library is to add functions that can *generally* be used. Explain that sentence when kernel code for now-useless SYN packets is a 'good idea'. No better example of the bastardisation they've caused is the requirement to compile using a *general c library for the 'kernel' and another *general* c library for kde and another *general* c library for redhat. The idiocy of a 'general' set of headers in /lib versus a 'general' set of headers for /usr/src/linux, versus an obsolete (but general) set of headers for 'legacy' api's. (ie ones they don't want to fix anymore, thinking of something even more brilliant) If you accept that 90% of truly *general* c functions have worked since year dot, that 10% of those get 'improved' and that 10% of the improved ones cause problems, those problems are insignificant. To mix this with 'improved' kernel functions is either an excercise in stupidty, or much more probably, and indictment of anal retentivity. They can't let go. We pride ourselves on slapping at Microsoft. Idiocy is often closer to $home. This situation will never improve, nor resolve, until the control-freak mentaility is removed from gcc / glibc. The kernel is NOT general and until it is removed from glib we will continue to live in interesting times. No real world busines would ever accept this degree of instability, they'd be fired. -- http://linux.nf -- [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Linux-users mailing list Archives, Digests, etc at http://linux.nf/mailman/listinfo/linux-users
Request for Assistance - Consulting Opportunity For Pay
Hello: Since I have great respect for the opinions and knowledge of the individuals on these lists, I'm humbly asking for your help. I've got the following problem: Linux 2.4.13 system GCC 2.95.3 In an attempt to upgrade the gcc to 3.0.2 and such I've somehow managed to break it badly...I'm fairly sure its not gcc that broken but rather the libc and glibc stuff thats messed up. I've attempted to restore it but obviously I'm not getting it right. The system is 100% functional if you don't mind I can't compile anything from source...LOL The problem is: I NEED to be able to do this in order to keep current with various packages (bind, apache, etc.). My question: I KNOW there is a way to recover and or reinstall the stuff in /lib /usr/local/lib and also the libc and glibc stuff to get this working. However, being a production box, I can't afford to mess this up and take the box down as I have paying customers that would be quite irritated by this turn of events (VBG). Ideally in this process I can get to the current revs of GCC and glibc, etc which is what started the problem in the first place. What I'm asking is: Is there ANYONE out there that know how to do this and would be willing to do the job FOR PAY in the very near future? REBUILDING THE BOX FROM SCRATCH IS NOT AN OPTION. Though I do do a full tape backup nightly, the time between the attempts and noticing they broke something is beyond the length of tapes I have here... The downtime to reconstruct the system would be prohibitive as well as its highly customized from its base Caldera OpenLinux 2.3 which went in about July of 1999 or so and honestly I don't know that I could recreate the system as it is now from that method. IF you have a better idea I'm all ears. I'm a small business and don't have a large bank account, but am willing to pay a fair price for a job done right. Replies OFF LIST would be appreciated. ===[George R. Kasica]===+1 262 677 0766 President +1 206 374 6482 FAX Netwrx Consulting Inc. Jackson, WI USA http://www.netwrx1.com [EMAIL PROTECTED] ICQ #12862186 ___ Linux-users mailing list Archives, Digests, etc at http://linux.nf/mailman/listinfo/linux-users
