Discuss May 2005

discuss@lists.centos.org

221 participants
344 discussions

Re: [CentOS] logrotate
by William Warren 29 May '05

29 May '05

Where are currently used .conf files kept? the /etc/logrotate.conf file does not contain any useful information. This is Centos 4 BTW. replies-lists-centos(a)listmail.innovate.net wrote: > between the man page for logrotate, the /etc/logrotate.conf file and > some of the files in the logrotate.d directory you should be able to > see all the bits necessary to accomplish what you're after. > > the /etc/logrotate.d/exim file gives you an example of wildcarding > the files that are included. > > by default, gzip deletes the file when compression is complete, so > you don't have a file delete issue. > > you'll probably need to use the "force" option during setup and > testing. > > > ------------ Original Message ------------ > >>Date: Sunday, May 29, 2005 10:06:20 AM -0400 >>From: William Warren <hescominsoon(a)emmanuelcomputerconsulting.com> >>To: CentOS mailing list <centos(a)centos.org> >>Subject: [CentOS] logrotate >> >>I am googgling right now but am unable to find a simpler >>description of how to get logrotate to do what i want it to do. >> >>I have a cs 1.6 server that generates quite a bit of logs. That >>log generation is going to increase significantly with one of my >>plugins i am going to be installing(logD and the impressive >>plugin). I want to tell logrotate to daily rotate all the logs >>inside my /servers/hlds/cstrike/logs folder. A new log is >>generated every map change and when any on-the-fly configuration is >>changed. Over the past 5 days there are 350 logfiles. How can i >>tel logrotate to rotate all of the individual logs in the folder, >>when rotating to compress them, store the compressed files in the >>same directory..delete the uncompressed logs..and not to delete any >>old logs for 6 months? >> >> >>-- >>Computer House Calls, Networks, Security, Web Design: >>http://www.emmanuelcomputerconsulting.com >>What businesses are in Brunswick, Maryland? Check Brunswick First! >>http://www.checkbrunswickfirst.com >>My "Foundation" verse: >>Isa 54:17 No weapon that is formed against thee shall prosper; and >>every tongue that shall rise against thee in judgment thou shalt >>condemn. This is the heritage of the servants of the LORD, and >>their righteousness is of me, saith the LORD. >> >>-- carpe ductum -- "Grab the tape" >>CDTT (Certified Duct Tape Technician) >> >>Linux user #322099 >>Machines: >>206822 >>256638 >>276825 >>http://counter.li.org/ >>_______________________________________________ >>CentOS mailing list >>CentOS(a)centos.org >>http://lists.centos.org/mailman/listinfo/centos > > > ---------- End Original Message ---------- > > -- Computer House Calls, Networks, Security, Web Design: http://www.emmanuelcomputerconsulting.com What businesses are in Brunswick, Maryland? Check Brunswick First! http://www.checkbrunswickfirst.com My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician) Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/

2 2

logrotate
by William Warren 29 May '05

29 May '05

I am googgling right now but am unable to find a simpler description of how to get logrotate to do what i want it to do. I have a cs 1.6 server that generates quite a bit of logs. That log generation is going to increase significantly with one of my plugins i am going to be installing(logD and the impressive plugin). I want to tell logrotate to daily rotate all the logs inside my /servers/hlds/cstrike/logs folder. A new log is generated every map change and when any on-the-fly configuration is changed. Over the past 5 days there are 350 logfiles. How can i tel logrotate to rotate all of the individual logs in the folder, when rotating to compress them, store the compressed files in the same directory..delete the uncompressed logs..and not to delete any old logs for 6 months? -- Computer House Calls, Networks, Security, Web Design: http://www.emmanuelcomputerconsulting.com What businesses are in Brunswick, Maryland? Check Brunswick First! http://www.checkbrunswickfirst.com My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician) Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/

1 0

Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Dag Wieers <dag(a)wieers.com> > I have a real problem with this thread. It seems as if, according to some, > someone can only be with or against Red Hat. Yes, that was my major complaint too. > I'm sure Red Hat has made stupid decisions, has adopted buggy software and > are responsible for some of the headaches people have had. And I'm sure > even Red Hat employees (like with any other distributor) would recognize > this. Agreed. If you attempt to please all people, you will fail utterly. Red Hat has its focus, pretty much all SLA-related on RHEL. Some people may demonize it as "that's where the money is" but in reality, it's because it's designed for paying customers who pay for those SLAs. At the same time, we still have Fedora Core. While people will debate over the merits of the greater Fedora Project in general, Fedora Core and RHEL are designed for two completely different sets of users. Just like RHEL was once it came out alongside RHL. Are there places in-between? Hell yes! And I like what I see in the CentOS project, where Red Hat has not addressed. But Red Hat already has 2 levels of focus, and I don't see them changing it. It seems to work, and work well for them. Novell-SuSE seems to be similar. But in the end, this is the reality that some people don't wake up to. They've got 3 choices: 1. Get involved with Fedora Core, which affects RHEL 2. Get involved with CentOS, which affects add-ons for their rebuild 3. Complaint, and nothing will change at all ;-> In reality, I typically ignore #3. The problem is when people do #3 and they just don't care to understand anything technical with FC-RHEL development and focus, and just get things dead wrong. Especially things that have redistribution and/or licensing issues, or the fact that sooner or later, newer versions have to be adopted. In fact, many people seem to be "wishy washy" on whether Red Hat should "hold back/backport" or "adopt newer" releases. The reality is that Red Hat doesn't ship anything in RHEL that hasn't been through Fedora Core prior (with rare exception, like MySQL 4 in RHEL4 that wasn't in FC2/FC3 -- kinda shocked even me). > But just pointing things out does not put you on one or the other side, > I may hope. Yes and no. No in the fact that your posts have made me aware of some considerations I never looked at before. That is a good thing. But yes, when people don't stop to understand the technical and licensing issues, let alone what RHEL's purpose is -- things that will _never_ change -- it's just bitching. It's one thing to complain in the hope of change, and even better to get involved. But bitching is just that -- the complaint that people are upset that CentOS doesn't do something out-of-the-box. And that means they blame Red Hat -- no matter where the actual blame _may_ fall. Worse yet, I've just sat back and actually let others attempt to explain how Red Hat wasn't involved in a decision (other projects did, which Red Hat merely simply complied with), and these "bitchers" will simply continue, and just make more comments that just show they have no interest in anything other than "bitching." It's beyond not being constructive, it's just flat out ignorance. That's what really gets to me. I can accept people aren't happy and wish for things. But when they want to blame Red Hat when there's nothing Red Hat can do about them, or they would radically change RHEL's focus to something that breaks the entire SLA model, then I just have to recognize that some people just won't see anything from another viewpoint. > I always have a sour taste in my mouth if you have to pick sides, because > that kills healthy rationalizing/critizing and often this has a hidden > agenda attached to it. Agreed. The problem is that many people who are "explaining" Red Hat are considered a "side" in the first place. I have been labeled a "Red HAt apologist" just for merely explaining many things that people will not believe is anything but a "Fedora Core / Red Hat-only bug." It doesn't matter how you explain it, there is always an avenue for them to assign blame to Red Hat -- and no one else. Ironically, if you have a SLA with Red Hat, they do take ownership of everything. Which is why RHEL is designed the way it is, to absolutely minimize anything that is not well package and integration tested. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Centos 4 on a portable hard drive..help!!
by Hugh Tollan 29 May '05

29 May '05

G'day one and all, I would like to install Centos 4 on a freecom classic hard drive (usb) ..the box I want to use can boot from removable devices. Any ideas how to go about installing onto the portable drive? If not can anyone point me in the right direction? I have tried to google but have not come up with much info....or info that I understand anyway!!!!! As usual, many thanks in advance. _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

Re: [CentOS] Re: CentOS and SL, together? -- GPL, LGPL, kernel and user ...
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Johnny Hughes <mailing-lists(a)hughesjr.com> > Sorry ... I was talking about the SRPM from SL ... it also build the > kernel modules ... Oh, right, sorry -- understand what you mean now. BTW, one of the worst assumptions I've seen is that because a distro or project ships something, its users believe it was done legally or with permission. I've seen many cases where things were never allowed to be redistributed, and they are no longer because the distro or project finally received a cease-and-desist letter. Not good if you're working in a company where people have installed it. Which is why I appreciate projects like Debian, Fedora, CentOS, etc... -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Re: CentOS and SL, together?
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: "Bryan J. Smith <b.j.smith(a)ieee.org>" <thebs413(a)earthlink.net> > Which is why I scratch my head. Especially when you compare what > people want and the fact that there's virtually no other company that > offers it. Even SuSE doesn't make it's 2 year guarantees, and they > are yanking support on SuSE Linux 7. Sorry, that last part should read "yanking support early on SuSE Linux Enterprise Server 7." Underpromise, overdeliver, that's always been the Red Hat way. Unfortunately, people seem to have taken their occassional past overdeliveries as policy. Especially since they were largely just short-lived, and never promised. -- Bryan J. Smith mailto:b.j.smith@ieee.org -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] CentOS and SL, together?
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Lamar Owen <lowen(a)pari.edu> > Referencing SL3 and CentOS 3 (as I haven't run SL4 as yet) there were some > scientific applications and some Java stuff, eclipse for one, You do understand the redistribution issues with Java, correct? It's a Sun problem (a typical thorn for Red Hat in general), not a Red Hat one. > part of cluster suite for another, included. > Lessee, > https://www.scientificlinux.org/distributions/30x/features/ is the reference. > GFS, Eclipse, Cluster Suite, OpenAFS, ksh93, a set of 'tweak' RPMs (my > favorite being the serial console tweak RPM). Red Hat is pushing to get GFS in the stock kernel. They bought out Sistina for a reason, to keep it GPL. These things don't happen overnight. ;-> GFS was introduced as an add-on, and probably will until it is in the stock kernel -- Red Hat is trying to avoid heavily patching the kernel nowdays (for various reasons). As far as OpenAFS, I assume you mean the server? Or you don't like Red Hat's included client in the kernel? As always, make a Bugzilla request if you want something. > For SL4, the doc is at > https://www.scientificlinux.org/distributions/4x/features/ and includes fewer > addons. OpenAFS is the biggest of these, I guess. And I too have deployed OpenAFS. The server is 100% userspace, so it shouldn't be too difficult to get it included, at least in Fedora Core (possibly the next RHEL5). > Once the cluster suite and eclipse are available they probably will be rolled in. Eclipse is now in Fedora Core 4. One thing to always remember that Eclipse's licensing is outside the control of Red Hat, and is IBM. It is also released under a non-GPL compatible license by IBM, and is similar in restriction to Sun/Mozilla licenses, so I'm sure Red Hat was hesitant to include it before. > The Fermi version of SL 3 had included a packaged JRE and was very attractive > for that, but later releases have not had that and rather have pointers to > download from sun. It is illegal to redistribute the JRE for Linux without a license. Again, see Sun for details. ;-> > Pine also is in the SL dists. Pico/Pine also changed licenses awhile back and is considered "non-free." Nano replaced Pico, can't remember what replaced Pine. Once again, I will remind people that an "enterprise/SLA" focused distro will rarely be focused on features. At the same time, it's clear that it requires many "enterprise" software packages built upon an "enterprise" distro -- which is not uncommon. Red Hat can't ship an "all-in-one" distro for enterprises -- and a SL solution is going to be on the other side of the spectrum from, say, a financial industry focused Linux. So Red Hat would rather ship a common base, supported by SLAs, and then sell add-ons with SLAs for a more specific configuration. If you want an industry-specific Linux, you're not going to find it from a generic distribution vendor. And you shouldn't wonder why they don't throw in things -- especially not things like Java which are _illegal_ to bundle freely. -- Bryan P.S. As always, maintain your own APT/YUM repository internally, and mix in any required RPMs. I virtually _never_ install from CD/DVD, almost always via NFS -- possibly with some post-install APT/YUM. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 3

Re: [CentOS] CentOS and SL, together?
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Johnny Hughes <mailing-lists(a)hughesjr.com> > Righto ... no JRE redistributes in CentOS ... that is not allowed :) > They also have mp3 stuff ... also not allowed :) If you want an example of what I consider "ignorance," that's it right there. Someone who asks, "why doesn't Red Hat include X," won't get grief. But people who say, "I use Y because it includes X and Red Hat does not," sorry, that's starting to play into that game. I have a rule at my clients: "No Linux CDs are allowed into the building until they are approved -- especially _not_ Knoppix." Why? Because I have to verify they are "pure" Linux and not an indemnification nightmare. > For CentOS-3.x you can get GFS (and RH ClusterSuite) here: > http://bender.it.swin.edu.au/centos-3/ > (there is no GFS/RHCS for RHEL-4 (or CentOS-4) yet) BTW, I haven't looked yet, is Netscape Directory Server available for CentOS? You can get it from the RHN (as well as the "technology preview"), just wondering if it's available for CentOS from another source. > OpenAFS: I'll have to look at the license that it is released under ... > that might be able to be in Extras ... someone want to maintain it :) IBM's IPL, yet another GPL-incompatible license along with IBM's CPL. People claim I have an "agenda" against IBM. No, but I _do_ have an "agenda" to get people to realize that they should hold IBM up against the same standard (and "agenda") they have against Sun. http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses Now the last time I checked, Red Hat did include the OpenAFS client in the kernel -- at least GPL portions (the history of AFS is a little interest). The OpenAFS server is user-space, so there is not a licensing issue there. I typically just download and build the full IPL licensed client/server from OpenAFS, despite the licensing issues. If it's for private use, you can do this per the GPL -- you just can't redistribute anything that isn't GPL compatible linked against GPL (which is what I make my clients aware of). BTW. If people think "ignorance" is a "harsh word," understand when you are "ignorant" as a consulting engineer with a Professional Engineering license, the term becomes "Professsional Negligence" with the same, _liability_ as an MD. ;-> So I tend to avoid "ignorance" and care about little details. ;-> > Correct ... Pine is non-free license, won't be built for CentOS-4 :) But remember, it's Red Hat's fault. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith 29 May '05

29 May '05

Even I've left this thread. I guess we're all waiting for Lee to turn Blue. ;-> Or is it Red (Hat)? ;-> Okay Lee, we all agree, Red Hat makes stupid decisions, adopts buggy software - especially the kernel and Red Hat is to blame for the decisions in the kernel, and also stupidly backports fixes instead of adopting newer versions with the fixes. And there is absolutely no need for Red Hat to do so. Happy? -----Original Message----- From: Les Mikesell Date: 05-5-28 0:55 To: CentOS mailing list Subj: Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan On Fri, 2005-05-27 at 19:13, Lamar Owen wrote: > On Thursday 26 May 2005 14:17, Les Mikesell wrote: > > If you believe that, you have to believe that Red Hat's programmers > > are always better than the original upstream program author. > > For the most part, the Red Hat crew is the best in the business. Or have you > never heard of Jakub Jelinek, Alan Cox, Rick van Riel, and many many other of > the top upstream developers that are employed in some capacity by Red Hat? I think we've beaten these topics to death, but since it is kind of fun if you don't take it too seriously: Which of these guys knows how to make perl do character set conversions correctly better than the perl team? > > I'll > > agree that they are good and on the average do a good job, but > > that stops far short of saying that they know better than the > > perl (etc.) teams what version you should be running. > > The perl team has no business telling me what version I should be running, > either. What version I run is dependent upon many things; one of which is > 'what version does my vendor support?' Sigh... at this point it is "how many versions does the vendor support"? And the issue is that the perl version (among many other things) that does a certain operation correctly is only included with a kernel version that has features missing and broken. > > So, you want a working application, take an incomplete kernel. I > > understand that's the way things are. I don't understand why > > you like it. > > Long term version stability. There has to be a freeze point; Red Hat has > chosen the very documented 2-2-2 6-6-6 scheme, and sticks to its schedule, > for the most part. Or, to put it very bluntly, just exactly which of the > over a thousand packages are worth waiting on? And who decides which package > holds up progress? CIPE, the example used here, is relatively insecure to > begin with and interoperates with nobody. I don't see how you can call setting up a WAN with many CIPE nodes, then finding it unavailable in the next release 'long term stability'. > Better to use IPsec (which > virtually everybody supports to a degree) than a relatively nonstandard VPN > like CIPE (I'd go as far as to say that most of the other VPN solutions are > in the same boat; what's needed on the server side is typically > Microsoft-compatible PPP over L2TP over IPsec, which is so easy to set up on > the Windows client side it isn't even funny). That's why for-purpose > firewall/VPN appliance Linux dists (SmoothWall and Astaro, for instance) are > not using anything but IPsec. I have a SmoothWall box myself, and it Just > Works. Can you run it through NAT routers? I have locations where the end point is already NATed by equipment I don't control. CIPE doesn't mind and the blowfish encryption is pretty CPU-friendly. And again, it might be "long-term stability" if this had already been a choice in several prior versions so you didn't have to upgrade OS revs on machines in several countries on the same day to keep your machines connected. > > Is there a reason that a Centos or third-party repository > > could not be arranged such that an explicit upgrade could be > > requested to a current version which would then be tracked like > > your kernel-xxx-version is when you select smp/hugemem/unsupported? >

4 5

Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Les Mikesell <lesmikesell(a)gmail.com> > No, I am looking for a solution that provides what a typical user needs, > not what a particular vendor feels like supporting this week. I didn't > really want this to be about motives for vendor's business decisions but > I think Johnny Hughes nailed it in saying the push for 2.6 was because > SLES 9 had it. Their decision wasn't stupid, but my point is that it > wasn't the best thing for some number of their old users. At what point does Red Hat hold off on adopting Linux 2.6? Or GCC 3? Or GLibC 2.0? As I said, there is a chicken-egg issue between "waiting for something to be well-tested with many packages" and "adopting something so it is well-tested with many packages." This existed back in the Red Hat Linux timeframe, and it still exists today. That's why RHEL is essentially based on the ".1" or ".2" release. Then it is kept fairly _static_ over its lifetime for SLA reasons. > However, I also support a number of general-purpose servers and some > desktops where a larger mix of applications need to be integrated > along with a variety of oddball hardware that has, over the years > been connected and supported one way or another. In this scenario > you are very likely to want to upgrade a single application and > find that you can't do it RedHat's-way(tm) because the bundled > upgrade will break something else that you need to keep running. And other "packages" distros don't have this problem? If you find Fedora Core + repositories doesn't solve what you need either, I think someone else pointed out that a "ports" distro, like Gentoo, might be more of what you are looking for. Especially if you're rolling out lots of "bleeding edge" distros. BTW, just so everyone knows, I support Debian, Fedora, Gentoo, NLD, RHEL, SuSE and SLES as a paid consultant. And I've been a maintainer in several projects so I'm not just a "Red Hat-only lacky" as many people believe. In fact, I am a software engineer at many clients (I just get stuck with the IT / configuration management because I seem to know how to do this with Linux better than the others around me). So I'm very partial to using "ports" distributions like Gentoo and BSD. ;-> > Explaining the reason the vendor made the decision that doesn't > work in my case isn't particularly helpful. Understanding why either allows you to: A) See what you can do to get the vendor to change, _or_ B) Better recognizing what you can do to accommodate the vendor I said it before and I'll say it again, one of the reasons I have very much sought after -- almost always by personal reference -- it because I can come in, look at someone's business/engineering model, and then architect a solution that maximizes the application of a solution while mitigating risk to any product changes. Unless you understand how and why the vendor is doing something, you can't either do "A" or "B" and customize the solution one way or another. The last thing my clients want to hear from me is "damn, Microsoft/RedHat/etc... broke your network." Furthermore, when architecting a solution, I can also give the client options and say, "if you go with RHEL, you're going to run into the re-occuring problem of X, Y and Z." In most cases, it helps me eliminate Microsoft from client consideration early on, but in some cases, I actually end up rolling out a completely _non-Red Hat_ solution. > You might as well try to explain to me why upgrading or installing > certain MS products require moving the whole enterprise to Active > Directory first. That's different, although the concepts are similiar. There is no vendor that can provide a solution that doesn't need accommodate at some point in a solution. Fortuntely, we don't have the "on-a-whim" changes in the RHEL space like we do in Windows -- _primarily_ _because_ Red Hat _never_ mixes in "new features" mid-release. But configuration management is _always_ an issue. You are _never_ going to eliminate much of it even in the Linux space. It is a necessary evil that you must do -- and that will vary on the focus of the distro. In fact, not doing configuration management in Linux roll-outs and, essentially, _falsifying_ the savings on Linux with it, is the absolute #1 reason why Linux projects fail. Having a background in defense, I liken this to NASA's COTS (commercial off-the-shelf) adoption in the '90s. After Sojouner (Mars Pathfinder) proved that GNU/VxWorks was a viable platform that cost 1/10th of custom software/hardware development, NASA's nexgen probes started adopting the same platforms/software as Pathfinder. The problem on these other projects is that the 90% savings was no longer applied to just software/hardware, but _all_ aspects of the project's budget. So unlike Sojouner, the QA (quality assurance) budget was cut. So when Mars Polar Lander entered the orbit assuming the units in a register were miles when they were, in fact, kilometers -- because there was not the QA between two engineering teams at two different companies several states away from each other -- I was not surprised one bit. Configuration management is quality assurance. You must do it and there will _never_ be a vendor, distro or other "off-the-shelf" solution that will allow you to avoid doing it. Because a solution is _never_ available that is customized for you and regression tested to work without issue. That's just reality. > I'm not really interested in playing a 'vendor lock-in' game. Okay, this is the typically spiral I see people do. They start talking about "vendor lock-in" with regards to Red Hat, applying their experiences with Microsoft. Sorry, this is _exactly_ the "demonization" I'm talking about. You are comparing the world's greatest, "we lack even proprietary standards" company to Red Hat, the absolute #1 pro-GPL commercial company. So there's _no_ sense in my responding further. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

← Newer
1
2
3
4
5
6
7
...
35
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss May 2005