[CentOS] free ftp server

[MOKRANI Rachid]

Hi,

I'm looking a linux freeware for sharing file with a web browser
interface - protect file by password, send link to download by email

Something like the following service:

https://www.yousendit.com/

http://www.hongkiat.com/blog/15-great-free-online-file-sharing-alternati
ves/



The idea is to install this service in OUR server for sharing files
beetwen other company. For differents reasons we don't want to store
some files in other servers.



Any idea about a software we can use in our local server ?


Thanks.



__

Ce message (et toutes ses pièces jointes éventuelles) est confidentiel et 
établi à l'intention exclusive de ses destinataires. Toute utilisation de ce 
message non conforme à sa destination, toute diffusion ou toute publication, 
totale ou partielle, est interdite, sauf autorisation expresse. L'IFP décline 
toute responsabilité au titre de ce message.

This message and any attachments (the message) are confidential and intended 
solely for the addressees. Any unauthorised use or dissemination is prohibited. 
IFP should not be liable for this message.

Visitez notre site Web / Visit our web site : http://www.ifp.fr
__
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] free ftp server

[Athmane Madjoudj]

On 06/18/2010 08:42 AM, MOKRANI Rachid wrote:
> Hi,
>
> I'm looking a linux freeware for sharing file with a web browser
> interface - protect file by password, send link to download by email
>
> Something like the following service:
>
> https://www.yousendit.com/
>
> http://www.hongkiat.com/blog/15-great-free-online-file-sharing-alternati
> ves/
>
>
>
> The idea is to install this service in OUR server for sharing files
> beetwen other company. For differents reasons we don't want to store
> some files in other servers.
>
>
>
> Any idea about a software we can use in our local server ?
>
>
> Thanks.
>

You can use:

- FTP/FTPS (FTP over SSL) eg: ProFTPd package in CentOS
- WebDAV: mod_dav in Apache
- Put the in HTTP server and protect the directory with pawword ie: 
htaccess/htpasswd

HTH



-- 
Athmane Madjoudj
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to measure file transfer speed?

[Theo Band]

hadi motamedi wrote:
> Dear All
> I have one centos server equipped with WiFi . I want to measure data
> rate speed on this connection . Is there any utility on my centos that
> can measure data speed on one specific Ethernet connection when
> transferring large size files through WiFi connection?
> Thank you
Nobody mentioned iftop? That's my personal favorite.
Just like top, but now for traffic.

Theo
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Kernel independent OCFS2 packages for RHEL, Scientific Linux and CentOS

[Dag Wieers]

Hi,

I would like to announce a set of OCFS2 kABI-tracking kernel module 
packages for RHEL5, Scientific Linux 5 and CentOS-5 and kernels. These 
packages have been introduced into the ELRepo testing repository 
(http://elrepo.org/).

You can find these packages at:

http://elrepo.org/linux/testing/el5/


The ELRepo project is a community project providing various additional kernel 
modules for Red Hat Enterprise Linux and derivative kernels that aim to be 
kernel independent. Next to this set of OCFS 1.4.7 kernel modules the 
project provides dozens of kmod RPM packages and hundreds of kernel 
modules for a variety of hardware and kernel functionality.


In this case we are looking for OCFS2 users willing to test these packages 
and provide feedback and support in our support channels for future 
users.

We welcome your feedback on our mailinglist and bug-tracker, respectively at:

http: //lists.elrepo.org/mailman/listinfo/elrepo
http: //elrepo.org/bugs/main_page.php

Kind regards,
-- 
--   dag wieers,  d...@wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[John Doe]

From: John R. Dennison 
> On Thu, Jun 17, 2010 at 08:09:11PM -0400, Whit Blauvelt wrote:
>> I should care what you believe?
> Is this vitriol really necessary?

I think it is just a reaction to the "I don't believe you at all", which some 
people would take as "you are a liar"...
That's the problem with internet communications.
The sender say things he would not say face to face, and the recipient does not 
know the "mood" of the sender.
Emoticons cannot completely solve it...  :/

JD


  
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] clustered file system of choice

[Peter Kjellstrom]

On Wednesday 16 June 2010, Boris Epstein wrote:
> On Wed, Jun 16, 2010 at 4:05 PM,   wrote:
> > Boris wrote:
> >> I am just trying to consider my options for storing a large mass of
> >> data (tens of terrabytes of files) and one idea is to build a
> >> clustered FS of some kind. Has anybody had any experience with that?
> >> Any recommendations?
> >
> > We've been looking at glusterfs here. It's under active development, has
> > some problems, but it does work, and is in use a number of places around
> > the world.
...
> Will surely check Glusterfs out. What's your thoughts on GPFS:
> http://en.wikipedia.org/wiki/GPFS ?

We run GPFS (and lustre) on CentOS-5(x86_64). GPFS is quite nice and very 
flexible but costs money. Lustre on the other hand is free and very scalable 
but lacks many of the features of GPFS.

Never tried Glusterfs and Ceph is not even close to mature enough for actual 
use (from what I've seen).

/Peter


signature.asc
Description: This is a digitally signed message part.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Yum problem on Centos 5.3 (64-bit)

[John Kelly]

Hello,

I'm having a yum problem updating a system on Centos 5.3, 64-bit ... 
i.e. 'yum update' returns "No Packages Marked for Update". Problem 
appears to be related to connecting to the mirrors where the 
repositories are located but I could be wrong in that. What's confusing 
me is that I have another system (Centos 5.5, 32-bit) that's working fine.

Best way to illustrate this is to show the output from the ("bad") 5.3 
system when I run 'yum -v list available'

[r...@servername yum]#  yum -v list available
Loading "fastestmirror" plugin
Loaded plugins: fastestmirror
Config time: 0.031
Running "init" handler for "fastestmirror" plugin
Yum Version: 3.2.19
COMMAND: yum -v list available
Installroot: /
Ext Commands:

   available
Setting up Package Sacks
Running "postreposetup" handler for "fastestmirror" plugin
Loading mirror speeds from cached hostfile
pkgsack time: 0.000
Reading Local RPMDB
rpmdb time: 0.000
Setting up Package Sacks
pkgsack time: 0.000

Similarly the the first few lines of the output from the ("good") 5.5 
system when I run 'yum -v list available'

[r...@other_server_name yum]# yum -v list available | more
Loading "fastestmirror" plugin
Config time: 0.032
Yum Version: 3.2.22
Setting up Package Sacks
Loading mirror speeds from cached hostfile
 * addons: anorien.csc.warwick.ac.uk
 * base: ftp.heanet.ie
 * extras: anorien.csc.warwick.ac.uk
 * updates: anorien.csc.warwick.ac.uk
pkgsack time: 0.029
rpmdb time: 0.000
Available Packages
Cluster_Administration-as-IN.noarch 5.2-1.el5.centos 
base
Cluster_Administration-bn-IN.noarch 5.2-1.el5.centos 
base

The contents of /var/cache/yum seems to be the same for both systems, as 
does the file /etc/yum.conf.

Would appreciate any thoughts on this.

Thanks,
John.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] BIND: listen-on and allow-recursion

[Niki Kovacs]

Hi,

I'm currently trying to get a grasp on DNS and Bind. I admit the 
documentation is quite confusing, either too laconic or way too 
detailed. So I'm trying to start from a working example, and then bite 
my way through it.

I have a sample named.conf file from Carla Schroder's Linux Cookbook. In 
the opening global options, I have this :

listen-on {
127.0.0.1;
10.11.12.1;
};
allow-recursion {
127.0.0.0/8;
10.11.12.0/24;
};

As far as I understand, the purpose of these two stanzas is to limit 
access to the DNS server to 1) the server itself and 2) the local 
10.11.12.0/24 network. In that case, there seems to be some redundancy 
in the syntax. Correct me if I'm wrong.

Can someone please explain (in plain words) the exact meaning of these 
stanzas ?

Thanks,

Niki
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] recognizing correct number of cores on CPU

[Jerry Geis]

I just installed centos 5.5 x86_64 on a new HP laptop.
It has the core i5 processor.

only 1 cpu is detected should be 2.

This has happened before. Is upstream not keeping up with
new processors released and updating the kernel?

I'd rather not go through the process again of putting a newer kernel
on the machine and having something different out there than "stock" centos.

Jerry
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] BIND: listen-on and allow-recursion

[John Doe]

From: Niki Kovacs 
> listen-on
> allow-recursion
> As far as I understand, the purpose of these two stanzas is to limit 
> access to the DNS server to 1) the server itself and 2) the local 
> 10.11.12.0/24 network. In that case, there seems to be some redundancy 
> in the syntax. Correct me if I'm wrong.

listen-on : the daemon will listen on these IPs for any dns queries
allow-recursion : IPs allowed to issue recursive queries
http://www.zytrax.com/books/dns/

JD


  
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[Whit Blauvelt]

On Thu, Jun 17, 2010 at 08:22:35PM -0500, John R. Dennison wrote:

>   Is this vitriol really necessary?  I installed ganglia; not a 
>   single conflict.

Why yes, John, it is. The fine man said outright he didn't believe my honest
account, accusing me of making something up when I was only giving the
facts. He was calling me a liar. He preferred to see my account as a lie so
as not to surrender his faith that Ganglia is a pure and perfect project.
Attitudes like that are dangerous in computing, since they lead to bugs not
being fixed.

>   If you want shiny and new, why not do it properly and build
>   rpms?

You installed without a conflict, good. Perhaps you were installing on a
32-bit system rather than a 64-bit? Perhaps your system didn't have some of
the packages already installed for other functionality that mine did? All I
can say is that, for my system, yum saw version conflicts that were
blockers.

As for "properly," there are, as Larry Wall says, many ways to do it. It is
up to each project, as their first task, IMHO, to see to it that
./configure, make, make install works for their package, with proper,
documented flags, on standard Linux distros. Ganglia - a fine and valuable
project on the whole - has a broken "make install." But it can be worked
around. Finding workarounds is often a sysadmins job. Sharing those
workarounds with the community is often how free software stays ahead of the
proprietary stuff. 

On the whole, this list is professional. I like that. But look,
"./configure, make, make install" is _always_ a proper option. Any serious
business will have need of building on occassional program with different
flags than the distro's default, whatever the distro. I often end up
building a few core applications that way, as do many other sysadmins in
serious business settings. If you don't need to, that's fine. Some
businesses can wear off-the-rack cloths. Others need tailored garments.

Regards,
Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[Whit Blauvelt]

On Thu, Jun 17, 2010 at 08:10:29PM -0500, John R. Dennison wrote:
> On Thu, Jun 17, 2010 at 08:01:02PM -0400, Joshua Baker-LePain wrote:
> > 
> > That being said, it's trivial to recompile the F13 RPM for 3.1.2 for 
> > centos-5.
> 
>   And that would be the proper route to go instead of building
>   from native source :)

To get 3.1.7? Disregarding that, I should jump through the hoops of
recompiling a F13 RPM rather than just compile from the tar? Why? Every
extra stage like that introduces the chance of incidental errors, of stuff
that doesn't translate precisely through that stage. I'm not doubting it
generally can work, just that there's anything "proper" about it. Generally
native source is the gold standard. The farther upstream you go, the better
the quality gets, the more bugs are fixed, and the more control you have
over how and where the stuff installs on your systems. 

There can be an argument that for some stuff that passes through RHEL the
extra attention adds some quality control (ignoring the counterexample of
the long history of RH manging kernels; they seem to have gotten better
about that lately), but stuff in EPEL? Really?

I'm not talking Linux from Scratch here - although I respect that project
immensely. I appreciate a solid distro as a foundation. CentOS is. But
claims that any distro is so perfect and complete that it's "improper" to
custom compile a few apps on its foundation - from the "native" source (with
all the connotations that "natives" are scarey and primitive) - should not
be well received if we want to continue to have open platforms.

Best,
Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[Nicolas Thierry-Mieg]

Whit Blauvelt wrote:
> On Thu, Jun 17, 2010 at 08:22:35PM -0500, John R. Dennison wrote:

>>  If you want shiny and new, why not do it properly and build
>>  rpms?
>

> On the whole, this list is professional. I like that. But look,
> "./configure, make, make install" is _always_ a proper option. Any serious
> business will have need of building on occassional program with different
> flags than the distro's default, whatever the distro. I often end up
> building a few core applications that way, as do many other sysadmins in
> serious business settings. If you don't need to, that's fine. Some
> businesses can wear off-the-rack cloths. Others need tailored garments.

you didn't get it Whit, John was not saying "stick to what's in the 
distro [or trusted 3rd party repos]".
He was suggesting to build your own rpms when needed. This allows you to 
use whatever version, build flags, options etc, just like your 
configure-make-make install solution. But it has many advantages, 
including easier housekeeping and dep management, deploying to many 
systems, pushing new versions, etc
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[Les Mikesell]

Whit Blauvelt wrote:
>
> You installed without a conflict, good. Perhaps you were installing on a
> 32-bit system rather than a 64-bit? Perhaps your system didn't have some of
> the packages already installed for other functionality that mine did? All I
> can say is that, for my system, yum saw version conflicts that were
> blockers.

That doesn't make any sense.  Yum pulls whatever it needs from the configured 
repos if you don't have them.  If yum sees conflicts on your system it is 
because you installed packages from somewhere other than the base and epel 
repos 
and thus shouldn't be blaming the package or packager.

> As for "properly," there are, as Larry Wall says, many ways to do it.

Yes, but none of them involve setting up unexpected conflicts with the base or 
epel repository packages.

> It is
> up to each project, as their first task, IMHO, to see to it that
> ./configure, make, make install works for their package, with proper,
> documented flags, on standard Linux distros. Ganglia - a fine and valuable
> project on the whole - has a broken "make install."

Did you mean to say it didn't run on your system?  Or that you didn't apply the 
changes in the rpm spec file before expecting it to work?

> On the whole, this list is professional. I like that. But look,
> "./configure, make, make install" is _always_ a proper option.

If you are careful to keep the results in /usr/local or /opt, maybe.  Otherwise 
you'll likely overwrite something that should be managed. And call things 
broken 
that are your own fault.

-- 
   Les Mikesell
lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[Whit Blauvelt]

On Thu, Jun 17, 2010 at 08:19:46PM -0500, John R. Dennison wrote:

>   I just tried a ganglia install from EPEL; absolutely no issues
>   at all.  Perhaps if you'd bother to actually document these
>   conflicts one of us might be able to help.  That is if we're
>   still willing.

Now you're threatening to expel me from the community? For posting notes on
workarounds to get a useful package to work? What's this about? Ganglia's
working fine for me.

>   I can't speak to your claims of 3.1.7 having bug fixes and
>   the multicpu issue; but I saw no conflicts with EPEL's 3.0.7.

My claims? The project's own documents describe this stuff. You saw no
conflicts? Great. Not every bug shows up on every box. You believe one
instance of not seeing a bug means no on else will? That's Microsoft-style
quality control.

> > If there were a good CentOS build of 3.1.7 I'd happily use it. But getting
> > stuff from EPEL, which is essentially Redhat testing, is as silly as mixing
> 
>   Uh, you've confused EPEL and Fedora apparently.

Sorry. If that's confusion, I got it from instructions (several sets of
them) out on the web for installing Ganglia from EPEL, which referred to it
as a Fedora repository. 

>   Gentoo is fine for a toy os.  Claiming Gentoo is "enterprise" is
>   just silly.

No point in including a long list of serious enterprises which run on
Gentoo. You're in fanboi mode and it's not your team. Fine.

>   Kids?  Heh.  17 years?  Heh.  You're a youngster.  Let me know
>   when you've got 25+ years in the industry and then I might be
>   impressed :)

I said I've been a Linux sysadmin since '93. I've been in the industry since
'82. Thanks for mistaking me for a youngster though!

Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] 5.5 & gspca

[JohnS]

On Thu, 2010-06-17 at 16:10 -0400, m.r...@5-cent.us wrote:

> 
> Ok, so I got the src rpm from el repo. Lessee, first I tried rpmbuild, and
> that failed, because it *required* xen-devel. So I grabbed the tarfile
> from /usr/src/redhat/SOURCES, unbzip2'd it, untar'd it, and did a make.
> And ten or so later, I had 265 kernel modules. I don't want or need to
> install all of that, so I tried just building gspca, and that failed with
> unresolved errors.
---
rpmbuild -ba  --target=i686 --nodeps video4linux-kmod-rt.spec

Wrote: /SRPMS/video4linux-kmod-0.0-5.20090615.el5.jerepo.src.rpm
Wrote: /RPMS/i686/kmod-video4linux-0.0-5.20090615.el5.jerepo.i686.rpm
Wrote: /RPMS/i686/kmod-video4linux-xen-0.0-5.20090615.el5.jerepo.i686.rpm
Wrote: /RPMS/i686/kmod-video4linux-PAE-0.0-5.20090615.el5.jerepo.i686.rpm
Wrote: /RPMS/i686/video4linux-kmod-debuginfo-0.0-5.20090615.el5.jerepo.i686.rpm

Use that command to build it.  You should get the above then trash xen,
pae and debug.  That builds and works on a pure kernel-rt install.
Allthough there things said left to do get it built the right way but it
is usable.

lib/modules/2.6.24.7-149.el5rt/extra/video4linux/ has several gspca
modules so your better off installing all to get the correct one.

John



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[Les Mikesell]

Whit Blauvelt wrote:
> On Thu, Jun 17, 2010 at 08:10:29PM -0500, John R. Dennison wrote:
>> On Thu, Jun 17, 2010 at 08:01:02PM -0400, Joshua Baker-LePain wrote:
>>> That being said, it's trivial to recompile the F13 RPM for 3.1.2 for 
>>> centos-5.
>>  And that would be the proper route to go instead of building
>>  from native source :)
> 
> To get 3.1.7? Disregarding that, I should jump through the hoops of
> recompiling a F13 RPM rather than just compile from the tar? Why?

Because rpm tracks all the files installed from packages, and yum understands 
the dependencies.  You've clearly broken that on your system.  And you probably 
have no idea how to verify that your tarball-installed files are still the same 
ones you installed or how to remove all of them cleanly.

> Every
> extra stage like that introduces the chance of incidental errors, of stuff
> that doesn't translate precisely through that stage. I'm not doubting it
> generally can work, just that there's anything "proper" about it. Generally
> native source is the gold standard. The farther upstream you go, the better
> the quality gets, the more bugs are fixed, and the more control you have
> over how and where the stuff installs on your systems. 

There's always a tradeoff between new code introducing new bugs and fixing old 
ones.  Fedora takes a different position in that tradeoff than RHEL/Centos and 
sometimes that's what you want for certain applications.  And if the src RPM 
will rebuild painlessly you get the advantage of rpm management for next to no 
extra work.  Plus you know someone else has at least run the code a time or 
two, 
something you don't know about the straight upstream source.

> There can be an argument that for some stuff that passes through RHEL the
> extra attention adds some quality control (ignoring the counterexample of
> the long history of RH manging kernels; they seem to have gotten better
> about that lately), but stuff in EPEL? Really?

One of EPEL's goals is to not overwrite or conflict with any base rpms.  They 
are't perfect, their idea of 'base' doesn't include centos extras, and their 
guidlines keep out some things you probably want, but in general they are 
pretty 
good and it is a very valuable thing to be able to install any of their 
packages 
without worrying about conflicts.  Other 3rd party repos don't make the same 
effort or intentionally update existing system libraries to meet their own 
goals.

> I'm not talking Linux from Scratch here - although I respect that project
> immensely. I appreciate a solid distro as a foundation. CentOS is. But
> claims that any distro is so perfect and complete that it's "improper" to
> custom compile a few apps on its foundation - from the "native" source (with
> all the connotations that "natives" are scarey and primitive) - should not
> be well received if we want to continue to have open platforms.

You need to think of rpm as a database with integrity rules - because that's 
what it is.  And think about what happens if you randomly scribble stuff in a 
database ignoring its rules - because that's what you are doing.  There are 
times you need to do some experimental things, but they should be kept out of 
the system area or you loose the advantage that package management tools 
provide.  Or you  should build your own rpms to incorporate the files into the 
system properly.

-- 
Les Mikesell
 lesmikes...@gmail.com


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[Jerry McAllister]

On Fri, Jun 18, 2010 at 08:14:02AM -0400, Whit Blauvelt wrote:

> On Thu, Jun 17, 2010 at 08:22:35PM -0500, John R. Dennison wrote:
> 
> > Is this vitriol really necessary?  I installed ganglia; not a 
> > single conflict.
> 
> Why yes, John, it is. The fine man said outright he didn't believe my honest
> account, accusing me of making something up when I was only giving the
> facts. He was calling me a liar. He preferred to see my account as a lie so
> as not to surrender his faith that Ganglia is a pure and perfect project.

there is a big difference in saying you don't believe a person's
information and calling them a liar.You may just be saying you
perceive things differently or maybe that the person doesn't understand
about which he is speaking.   He may be entirely truthful and still
not be believed.


jerry



> Attitudes like that are dangerous in computing, since they lead to bugs not
> being fixed.
> 
> > If you want shiny and new, why not do it properly and build
> > rpms?
> 
> You installed without a conflict, good. Perhaps you were installing on a
> 32-bit system rather than a 64-bit? Perhaps your system didn't have some of
> the packages already installed for other functionality that mine did? All I
> can say is that, for my system, yum saw version conflicts that were
> blockers.
> 
> As for "properly," there are, as Larry Wall says, many ways to do it. It is
> up to each project, as their first task, IMHO, to see to it that
> ./configure, make, make install works for their package, with proper,
> documented flags, on standard Linux distros. Ganglia - a fine and valuable
> project on the whole - has a broken "make install." But it can be worked
> around. Finding workarounds is often a sysadmins job. Sharing those
> workarounds with the community is often how free software stays ahead of the
> proprietary stuff. 
> 
> On the whole, this list is professional. I like that. But look,
> "./configure, make, make install" is _always_ a proper option. Any serious
> business will have need of building on occassional program with different
> flags than the distro's default, whatever the distro. I often end up
> building a few core applications that way, as do many other sysadmins in
> serious business settings. If you don't need to, that's fine. Some
> businesses can wear off-the-rack cloths. Others need tailored garments.
> 
> Regards,
> Whit
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] free ftp server

[Greg Bailey]

MOKRANI Rachid wrote:
> Hi,
>
> I'm looking a linux freeware for sharing file with a web browser
> interface - protect file by password, send link to download by email
>
> Something like the following service:
>
> https://www.yousendit.com/
>
> http://www.hongkiat.com/blog/15-great-free-online-file-sharing-alternati
> ves/
>
> The idea is to install this service in OUR server for sharing files
> beetwen other company. For differents reasons we don't want to store
> some files in other servers.
>
> Any idea about a software we can use in our local server ?
>
>
> Thanks.
>
>   

One I've used that has some of these features is "dl: download ticket 
service", available at:

http://www.thregr.org/~wavexx/software/dl/
http://freshmeat.net/projects/dl-ticket-service

-Greg

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] 5.5 & gspca

[Ned Slider]

On 18/06/10 14:10, JohnS wrote:
>
> On Thu, 2010-06-17 at 16:10 -0400, m.r...@5-cent.us wrote:
>
>> 
>> Ok, so I got the src rpm from el repo. Lessee, first I tried rpmbuild, and
>> that failed, because it *required* xen-devel. So I grabbed the tarfile
>> from /usr/src/redhat/SOURCES, unbzip2'd it, untar'd it, and did a make.
>> And ten or so later, I had 265 kernel modules. I don't want or need to
>> install all of that, so I tried just building gspca, and that failed with
>> unresolved errors.
> ---
> rpmbuild -ba  --target=i686 --nodeps video4linux-kmod-rt.spec
>
> Wrote: /SRPMS/video4linux-kmod-0.0-5.20090615.el5.jerepo.src.rpm
> Wrote: /RPMS/i686/kmod-video4linux-0.0-5.20090615.el5.jerepo.i686.rpm
> Wrote: /RPMS/i686/kmod-video4linux-xen-0.0-5.20090615.el5.jerepo.i686.rpm
> Wrote: /RPMS/i686/kmod-video4linux-PAE-0.0-5.20090615.el5.jerepo.i686.rpm
> Wrote: 
> /RPMS/i686/video4linux-kmod-debuginfo-0.0-5.20090615.el5.jerepo.i686.rpm
>
> Use that command to build it.  You should get the above then trash xen,
> pae and debug.  That builds and works on a pure kernel-rt install.
> Allthough there things said left to do get it built the right way but it
> is usable.
>
> lib/modules/2.6.24.7-149.el5rt/extra/video4linux/ has several gspca
> modules so your better off installing all to get the correct one.
>
> John
>

No, define kvariants as appropriate and only build for the variants you 
want.

http://wiki.centos.org/HowTos/BuildingKernelModules#head-b86b6eec08d5719cf1838929f26a64af88e2b7f0

rpmbuild -ba  --target=i686 --define 'kvariants ""' video4linux-kmod.spec

If you don't, then by default the package will be built for *all* kernel 
variants and you will of course need the appropriate BuildRequires 
installed on your build system (eg, kernel-devel, kernel-xen-devel, 
kernel-PAE-devel).

Also, you can't just install the modules you want as there are also 
kernel module dependencies to consider. For example, your required gspca 
module might depend on gspca_main which might depend on videodev, which 
might depend on v4l2-compat-ioctl32, v4l1-compat etc. And you can't just 
update those modules because something else might also depend on them 
and it's dependencies will then be broken. This is why we package the 
whole lot - so you don't get screwed up dependencies. I admit it's not a 
perfect solution, and is very much one size fits all but if your 
hardware is not detected by the EL5 kernel then it is the simplest option.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[Whit Blauvelt]

> On Thu, Jun 17, 2010 at 08:19:46PM -0500, John R. Dennison wrote:

> > > If there were a good CentOS build of 3.1.7 I'd happily use it. But getting
> > > stuff from EPEL, which is essentially Redhat testing, is as silly as 
> > > mixing
> > 
> > Uh, you've confused EPEL and Fedora apparently.

Hey John,

https://fedoraproject.org/wiki/EPEL:

"Extra Packages for Enterprise Linux (EPEL) is a volunteer-based community
effort from the Fedora project to create a repository of high-quality add-on
..."

Enough said.

Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recognizing correct number of cores on CPU

[Peter Kjellstrom]

On Friday 18 June 2010, Jerry Geis wrote:
> I just installed centos 5.5 x86_64 on a new HP laptop.
> It has the core i5 processor.
>
> only 1 cpu is detected should be 2.
>
> This has happened before. Is upstream not keeping up with
> new processors released and updating the kernel?

I've used the stock CentOS kernel with even unreleased CPUs, there is no 
general need for CPU to be supported.

Maybe this is a bios problem.

More information would also be nice (like dmesg output).

/Peter

> I'd rather not go through the process again of putting a newer kernel
> on the machine and having something different out there than "stock"
> centos.
>
> Jerry


signature.asc
Description: This is a digitally signed message part.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] 5.5 & gspca

[JohnS]

On Fri, 2010-06-18 at 14:50 +0100, Ned Slider wrote:
> On 18/06/10 14:10, JohnS wrote:
> >
> > On Thu, 2010-06-17 at 16:10 -0400, m.r...@5-cent.us wrote:
> >
> >> 
> >> Ok, so I got the src rpm from el repo. Lessee, first I tried rpmbuild, and
> >> that failed, because it *required* xen-devel. So I grabbed the tarfile
> >> from /usr/src/redhat/SOURCES, unbzip2'd it, untar'd it, and did a make.
> >> And ten or so later, I had 265 kernel modules. I don't want or need to
> >> install all of that, so I tried just building gspca, and that failed with
> >> unresolved errors.
> > ---
> > rpmbuild -ba  --target=i686 --nodeps video4linux-kmod-rt.spec
> >
> > Wrote: /SRPMS/video4linux-kmod-0.0-5.20090615.el5.jerepo.src.rpm
> > Wrote: /RPMS/i686/kmod-video4linux-0.0-5.20090615.el5.jerepo.i686.rpm
> > Wrote: /RPMS/i686/kmod-video4linux-xen-0.0-5.20090615.el5.jerepo.i686.rpm
> > Wrote: /RPMS/i686/kmod-video4linux-PAE-0.0-5.20090615.el5.jerepo.i686.rpm
> > Wrote: 
> > /RPMS/i686/video4linux-kmod-debuginfo-0.0-5.20090615.el5.jerepo.i686.rpm
> >
> > Use that command to build it.  You should get the above then trash xen,
> > pae and debug.  That builds and works on a pure kernel-rt install.
> > Allthough there things said left to do get it built the right way but it
> > is usable.
> >
> > lib/modules/2.6.24.7-149.el5rt/extra/video4linux/ has several gspca
> > modules so your better off installing all to get the correct one.
> >
> > John
> >
> 
> No, define kvariants as appropriate and only build for the variants you 
> want.
> 
> http://wiki.centos.org/HowTos/BuildingKernelModules#head-b86b6eec08d5719cf1838929f26a64af88e2b7f0
> 
> rpmbuild -ba  --target=i686 --define 'kvariants ""' video4linux-kmod.spec
> 
> If you don't, then by default the package will be built for *all* kernel 
> variants and you will of course need the appropriate BuildRequires 
> installed on your build system (eg, kernel-devel, kernel-xen-devel, 
> kernel-PAE-devel).
---
Would you so nicely post that on the appropiate page elsewhere please.?

 rpmbuild -ba  --target=i686 --define 'kvariants "rt"'
video4linux-kmod.spec

This is a bug also In my opinion because kmodtool should not allow the
nodepts parameter to be used.

It was by luck I decided to try """rt""".  You see my idiot self tried
kernel-rt there lol.  So this is the right way correct? 

Build is running with only installed kernel-rt and kernel-rt-devel:
 2.6.24.7-149.el5rt #1 SMP PREEMPT RT 

We will see if it indeed works later on tonight.

John

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recognizing correct number of cores on CPU

[JJ]

-Original Message-
From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf
Of Peter Kjellstrom
Sent: Friday, June 18, 2010 9:19 AM
To: centos@centos.org
Cc: Jerry Geis
Subject: Re: [CentOS] recognizing correct number of cores on CPU

On Friday 18 June 2010, Jerry Geis wrote:
> I just installed centos 5.5 x86_64 on a new HP laptop.
> It has the core i5 processor.
>
> only 1 cpu is detected should be 2.
>
> This has happened before. Is upstream not keeping up with new 
> processors released and updating the kernel?

I've used the stock CentOS kernel with even unreleased CPUs, there is no
general need for CPU to be supported.

Maybe this is a bios problem.

More information would also be nice (like dmesg output).

/Peter

> I'd rather not go through the process again of putting a newer kernel 
> on the machine and having something different out there than "stock"
> centos.
>
> Jerry

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] 5.5 & gspca

[JohnS]

On Fri, 2010-06-18 at 10:22 -0400, JohnS wrote:

> > 
> > http://wiki.centos.org/HowTos/BuildingKernelModules#head-b86b6eec08d5719cf1838929f26a64af88e2b7f0
> > 
> > rpmbuild -ba  --target=i686 --define 'kvariants ""' video4linux-kmod.spec
> > 
> > If you don't, then by default the package will be built for *all* kernel 
> > variants and you will of course need the appropriate BuildRequires 
> > installed on your build system (eg, kernel-devel, kernel-xen-devel, 
> > kernel-PAE-devel).
> ---
> Would you so nicely post that on the appropiate page elsewhere please.?
> 
>  rpmbuild -ba  --target=i686 --define 'kvariants "rt"'
> video4linux-kmod.spec
---
Let me clarify that.  What I mean is the "kvariants" as in what variants
there is.  How to use the kmod tool from the command line also.  What I
don't know for sure is if "rt" is correct?  It's the only way it will
build with --define kvariants.  More to be found out.

John

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[Les Mikesell]

On 6/18/2010 9:01 AM, Whit Blauvelt wrote:
>
 If there were a good CentOS build of 3.1.7 I'd happily use it. But getting
 stuff from EPEL, which is essentially Redhat testing, is as silly as mixing
>>>
>>> Uh, you've confused EPEL and Fedora apparently.
>
> Hey John,
>
> https://fedoraproject.org/wiki/EPEL:
>
> "Extra Packages for Enterprise Linux (EPEL) is a volunteer-based community
> effort from the Fedora project to create a repository of high-quality add-on
> ..."
>
> Enough said.

Apparently not, since you don't seem to understand the purpose of the 
project, the relationship to the sponsor organization, or the value of 
high-quality, well maintained packages.  Or even the value of having 
machines where for spans of many years, all you ever have to do is "yum 
update" and the right thing will happen to every installed application.

-- 
   Les Mikesell
lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recognizing correct number of cores on CPU

[Jerry Geis]

Peter Kjellstrom wrote:
> On Friday 18 June 2010, Jerry Geis wrote:
>   
>> I just installed centos 5.5 x86_64 on a new HP laptop.
>> It has the core i5 processor.
>>
>> only 1 cpu is detected should be 2.
>>
>> This has happened before. Is upstream not keeping up with
>> new processors released and updating the kernel?
>> 
>
> I've used the stock CentOS kernel with even unreleased CPUs, there is no 
> general need for CPU to be supported.
>
> Maybe this is a bios problem.
>
> More information would also be nice (like dmesg output).
>
> /Peter
>
>   
>> I'd rather not go through the process again of putting a newer kernel
>> on the machine and having something different out there than "stock"
>> centos.
>>
>> Jerry
>> 

more /proc/cpuinfo is showing:
 more /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 37
model name  : Intel(R) Core(TM) i5 CPU   M 430  @ 2.27GHz
stepping: 2
cpu MHz : 2261.291
cache size  : 3072 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 11
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall 
nx rdtscp lm constant_tsc up ida nonstop_tsc arat pni monitor ds_cpl vmx 
est tm2 ssse3 cx16
xtpr sse4_1 sse4_2 popcnt lahf_lm
bogomips: 4522.58
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management: [8]


dmesg is :

Linux version 2.6.18-194.3.1.el5 (mockbu...@builder10.centos.org) (gcc version 
4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu May 13 13:08:30 EDT 2010
Command line: ro root=LABEL=/ rhgb quiet noapic acpi=off apci=off
BIOS-provided physical RAM map:
 BIOS-e820: 0001 - 0009d000 (usable)
 BIOS-e820: 0009d000 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - bf63f000 (usable)
 BIOS-e820: bf63f000 - bf6bf000 (reserved)
 BIOS-e820: bf6bf000 - bf7bf000 (ACPI NVS)
 BIOS-e820: bf7bf000 - bf7ff000 (ACPI data)
 BIOS-e820: bf7ff000 - bf80 (usable)
 BIOS-e820: bf80 - c000 (reserved)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: feb0 - feb04000 (reserved)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fed1 - fed14000 (reserved)
 BIOS-e820: fed18000 - fed1a000 (reserved)
 BIOS-e820: fed1b000 - fed2 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: ffe8 - 0001 (reserved)
 BIOS-e820: 0001 - 00013c00 (usable)
DMI 2.6 present.
No NUMA configuration found
Faking a node at -00013c00
Bootmem setup node 0 -00013c00
No mptable found.
Memory for crash kernel (0x0 to 0x0) notwithin permissible range
disabling kdump
On node 0 totalpages: 1010585
  DMA zone: 2625 pages, LIFO batch:0
  DMA32 zone: 765560 pages, LIFO batch:31
  Normal zone: 242400 pages, LIFO batch:31
Nosave address range: 0009d000 - 000a
Nosave address range: 000a - 000e
Nosave address range: 000e - 0010
Nosave address range: bf63f000 - bf6bf000
Nosave address range: bf6bf000 - bf7bf000
Nosave address range: bf7bf000 - bf7ff000
Nosave address range: bf80 - c000
Nosave address range: c000 - e000
Nosave address range: e000 - f000
Nosave address range: f000 - feb0
Nosave address range: feb0 - feb04000
Nosave address range: feb04000 - fec0
Nosave address range: fec0 - fec01000
Nosave address range: fec01000 - fed1
Nosave address range: fed1 - fed14000
Nosave address range: fed14000 - fed18000
Nosave address range: fed18000 - fed1a000
Nosave address range: fed1a000 - fed1b000
Nosave address range: fed1b000 - fed2
Nosave address range: fed2 - fee0
Nosave address range: fee0 - fee01000
Nosave address range: fee01000 - ffe8
Nosave address range: ffe8 - 0001
Allocating PCI resources starting at c200 (gap: c000:2000)
SMP: Allowing 0 CPUs, 0 hotplug CPUs
Built 1 zonelists.  Total pages: 1010585
Kernel command line: ro root=LABEL=/ rhgb quiet noapic acpi=off apci=off
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour VGA+ 80x25
Den

Re: [CentOS] Ganglia

[Les Mikesell]

On 6/18/2010 8:20 AM, Jerry McAllister wrote:
> On Fri, Jun 18, 2010 at 08:14:02AM -0400, Whit Blauvelt wrote:
>
>> On Thu, Jun 17, 2010 at 08:22:35PM -0500, John R. Dennison wrote:
>>
>>> Is this vitriol really necessary?  I installed ganglia; not a
>>> single conflict.
>>
>> Why yes, John, it is. The fine man said outright he didn't believe my honest
>> account, accusing me of making something up when I was only giving the
>> facts. He was calling me a liar. He preferred to see my account as a lie so
>> as not to surrender his faith that Ganglia is a pure and perfect project.
>
> there is a big difference in saying you don't believe a person's
> information and calling them a liar.You may just be saying you
> perceive things differently or maybe that the person doesn't understand
> about which he is speaking.   He may be entirely truthful and still
> not be believed.

And there's a gray area where what the person says is technically true 
regarding his observations but then he places blame on others for a 
situation he created himself.  The part not to be believed is the 
incorrect conclusion, especially when you can easily disprove it 
yourself - so its not a lie, it is a mistake.

-- 
   Les Mikesell
lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] 5.5 & gspca

[JohnS]

On Fri, 2010-06-18 at 14:50 +0100, Ned Slider wrote:
> On 18/06/10 14:10, JohnS wrote:
> >
> > On Thu, 2010-06-17 at 16:10 -0400, m.r...@5-cent.us wrote:
> >
> >> 
> >> Ok, so I got the src rpm from el repo. Lessee, first I tried rpmbuild, and
> >> that failed, because it *required* xen-devel. So I grabbed the tarfile
> >> from /usr/src/redhat/SOURCES, unbzip2'd it, untar'd it, and did a make.
> >> And ten or so later, I had 265 kernel modules. I don't want or need to
> >> install all of that, so I tried just building gspca, and that failed with
> >> unresolved errors.
> > ---
> > rpmbuild -ba  --target=i686 --nodeps video4linux-kmod-rt.spec
> >
> > Wrote: /SRPMS/video4linux-kmod-0.0-5.20090615.el5.jerepo.src.rpm
> > Wrote: /RPMS/i686/kmod-video4linux-0.0-5.20090615.el5.jerepo.i686.rpm
> > Wrote: /RPMS/i686/kmod-video4linux-xen-0.0-5.20090615.el5.jerepo.i686.rpm
> > Wrote: /RPMS/i686/kmod-video4linux-PAE-0.0-5.20090615.el5.jerepo.i686.rpm
> > Wrote: 
> > /RPMS/i686/video4linux-kmod-debuginfo-0.0-5.20090615.el5.jerepo.i686.rpm
> >
> > Use that command to build it.  You should get the above then trash xen,
> > pae and debug.  That builds and works on a pure kernel-rt install.
> > Allthough there things said left to do get it built the right way but it
> > is usable.
> >
> > lib/modules/2.6.24.7-149.el5rt/extra/video4linux/ has several gspca
> > modules so your better off installing all to get the correct one.
> >
> > John
> >
> 
> No, define kvariants as appropriate and only build for the variants you 
> want.
> 
> http://wiki.centos.org/HowTos/BuildingKernelModules#head-b86b6eec08d5719cf1838929f26a64af88e2b7f0
> 
> rpmbuild -ba  --target=i686 --define 'kvariants ""' video4linux-kmod.spec
> 
> If you don't, then by default the package will be built for *all* kernel 
> variants and you will of course need the appropriate BuildRequires 
> installed on your build system (eg, kernel-devel, kernel-xen-devel, 
> kernel-PAE-devel).

rpmbuild -ba  --target=i686 --define 'kvariants "rt"'
video4linux-kmod.spec

Wrote: /SRPMS/video4linux-kmod-0.0-5.20090615.el5.elrepo.src.rpm
Wrote: /RPMS/i686/kmod-video4linux-rt-0.0-5.20090615.el5.elrepo.i686.rpm
Wrote: /RPMS/i686/video4linux-kmod-debuginfo-0.0-5.20090615.el5.elrepo.i686.rpm

Nice.. Will check usability out tonight. 

John

Warning:
elrepo.org does not offer kmods for kernel-rt. This is just a rebuild
test by none other than myself to test compatability and interest.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recognizing correct number of cores on CPU

[Peter Kjellstrom]

On Friday 18 June 2010, Jerry Geis wrote:
> Peter Kjellstrom wrote:
...
> > More information would also be nice (like dmesg output).
> >
> > /Peter
> >
> >> I'd rather not go through the process again of putting a newer kernel
> >> on the machine and having something different out there than "stock"
> >> centos.
> >>
> >> Jerry
>
> more /proc/cpuinfo is showing:
>  more /proc/cpuinfo
> processor   : 0
> vendor_id   : GenuineIntel
> cpu family  : 6
> model   : 37
> model name  : Intel(R) Core(TM) i5 CPU   M 430  @ 2.27GHz
...
> dmesg is :
>
> Linux version 2.6.18-194.3.1.el5 (mockbu...@builder10.centos.org) (gcc
> version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu May 13 13:08:30 EDT
> 2010 Command line: ro root=LABEL=/ rhgb quiet noapic acpi=off apci=off

I think this is the problem, acpi=off, that will (if I remember correctly) 
essentially disable smp.

/Peter

> BIOS-provided physical RAM map:
...


signature.asc
Description: This is a digitally signed message part.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recognizing correct number of cores on CPU

[Paul Heinlein]

On Fri, 18 Jun 2010, Jerry Geis wrote:

> Peter Kjellstrom wrote:
>> On Friday 18 June 2010, Jerry Geis wrote:
>>
>>> I just installed centos 5.5 x86_64 on a new HP laptop.
>>> It has the core i5 processor.
>>>
>>> only 1 cpu is detected should be 2.
>>>
> dmesg is :
>
> Linux version 2.6.18-194.3.1.el5 (mockbu...@builder10.centos.org) (gcc 
> version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu May 13 13:08:30 EDT 2010
> Command line: ro root=LABEL=/ rhgb quiet noapic acpi=off apci=off

I'll admit that I've never had to resort to "acpi=off", but my 
multi-core system all boot with a dmesg that says

   Using ACPI (MADT) for SMP configuration information

In particular, your system reported

> SMP: Allowing 0 CPUs, 0 hotplug CPUs

That doesn't look right. It should report that it allows multiple 
CPUs.

Can you boot this system without turning off acpi?

-- 
Paul Heinlein <> heinl...@madboa.com <> http://www.madboa.com/
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recognizing correct number of cores on CPU

[Jerry Geis]

Peter Kjellstrom wrote:
> On Friday 18 June 2010, Jerry Geis wrote:
>   
>> Peter Kjellstrom wrote:
>> 
> ...
>   
>>> More information would also be nice (like dmesg output).
>>>
>>> /Peter
>>>
>>>   
 I'd rather not go through the process again of putting a newer kernel
 on the machine and having something different out there than "stock"
 centos.

 Jerry
 
>> more /proc/cpuinfo is showing:
>>  more /proc/cpuinfo
>> processor   : 0
>> vendor_id   : GenuineIntel
>> cpu family  : 6
>> model   : 37
>> model name  : Intel(R) Core(TM) i5 CPU   M 430  @ 2.27GHz
>> 
> ...
>   
>> dmesg is :
>>
>> Linux version 2.6.18-194.3.1.el5 (mockbu...@builder10.centos.org) (gcc
>> version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu May 13 13:08:30 EDT
>> 2010 Command line: ro root=LABEL=/ rhgb quiet noapic acpi=off apci=off
>> 
>
> I think this is the problem, acpi=off, that will (if I remember correctly) 
> essentially disable smp.
>
> /Peter
>
>   
>> BIOS-provided physical RAM map:
>> 
> ...
>   
I added the "noapic acpi=off and apci=off" as without them the install 
processs died.
I dont have the exact message any longer.

jerry
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Migrating away from Nagios

[Joseph L. Casale]

I have to rebuild a new Nagios box and thought this might be a good time
to migrate away. I use snmp mostly for everything but with the fork Nagios
endured I wonder about putting any more effort into the project.

I probably should look at OpenNMS again, but the other options I think might
work are Icinga (Should be trivial to migrate) or Zenoss or maybe even Zabbix?

Anyone have experience in Nagios and care to share comparisons with similar
projects with strong community involvement?

Also, anyone currently running OpenNMS that can comment on the learning curve
and level of flexibility coming from a Nagios user?

Thanks!
jlc
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Migrating away from Nagios

[Baird, Josh]

I am a pretty hardcore ZenOSS user.. We use it to monitor over 1000
devices in different fashions - using a combination of SNMP (Linux), WMI
(windows) and SSH (Unix/Aix).  While there is a slight learning curve to
get everything working the way you want - it is, in my opinion, the most
powerful open source NMS.  It is a very active project with excellent
community (and even commercial) support.

I'd definitely suggest that you take a look at it.

Josh

-Original Message-
From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On
Behalf Of Joseph L. Casale
Sent: Friday, June 18, 2010 10:32 AM
To: 'centos@centos.org'
Subject: [CentOS] Migrating away from Nagios

I have to rebuild a new Nagios box and thought this might be a good time
to migrate away. I use snmp mostly for everything but with the fork
Nagios
endured I wonder about putting any more effort into the project.

I probably should look at OpenNMS again, but the other options I think
might
work are Icinga (Should be trivial to migrate) or Zenoss or maybe even
Zabbix?

Anyone have experience in Nagios and care to share comparisons with
similar
projects with strong community involvement?

Also, anyone currently running OpenNMS that can comment on the learning
curve
and level of flexibility coming from a Nagios user?

Thanks!
jlc
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] 5.5 & gspca

[m . roth]

JohnS wrote:
>
> On Thu, 2010-06-17 at 16:10 -0400, m.r...@5-cent.us wrote:
>> 
>> Ok, so I got the src rpm from el repo. Lessee, first I tried rpmbuild,
>> and
>> that failed, because it *required* xen-devel. So I grabbed the tarfile
>> from /usr/src/redhat/SOURCES, unbzip2'd it, untar'd it, and did a make.
>> And ten or so later, I had 265 kernel modules. I don't want or need to
>> install all of that, so I tried just building gspca, and that failed
>> with unresolved errors.
> ---
> rpmbuild -ba  --target=i686 --nodeps video4linux-kmod-rt.spec
>
> Wrote: /SRPMS/video4linux-kmod-0.0-5.20090615.el5.jerepo.src.rpm
> Wrote: /RPMS/i686/kmod-video4linux-0.0-5.20090615.el5.jerepo.i686.rpm
> Wrote: /RPMS/i686/kmod-video4linux-xen-0.0-5.20090615.el5.jerepo.i686.rpm
> Wrote: /RPMS/i686/kmod-video4linux-PAE-0.0-5.20090615.el5.jerepo.i686.rpm
> Wrote:
> /RPMS/i686/video4linux-kmod-debuginfo-0.0-5.20090615.el5.jerepo.i686.rpm
>
> Use that command to build it.  You should get the above then trash xen,
> pae and debug.  That builds and works on a pure kernel-rt install.
> Allthough there things said left to do get it built the right way but it
> is usable.

Um, what's kernel-rt got to do with anything I said? And actually, the
first server I'm trying to build this on is a Sunfire, but it's running
Opterons, and the o/s is 64-bit. I also do *not* have any xen installed.

Fine, I tried running
 rpmbuild -ba --target=x86_64 --without xen video4linux-kmod.spec
Building target platforms: x86_64
Building for target x86_64
error: Failed build dependencies:
kernel-xen-devel-x86_64 = 2.6.18-194.3.1.el5 is needed by
video4linux-kmod-0.0-5.20090615.el5.elrepo.x86_64

My last trick was to edit the stupid spec file, and comment out
#%ifarch i686 x86_64
#%define xenvar xen
#%endif
and it *still* wants to build for xen.

No, the rpmbuild is not correct. So, back to the original, of trying to
figure out just what kernel modules I need to install, rather than the
laundry list it correctly builds when I drop the rpm, and build from the
blown-out tarfile.

  mark

>
> lib/modules/2.6.24.7-149.el5rt/extra/video4linux/ has several gspca
> modules so your better off installing all to get the correct one.
>
> John
>
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Migrating away from Nagios

[Les Mikesell]

On 6/18/2010 10:31 AM, Joseph L. Casale wrote:
> I have to rebuild a new Nagios box and thought this might be a good time
> to migrate away. I use snmp mostly for everything but with the fork Nagios
> endured I wonder about putting any more effort into the project.
>
> I probably should look at OpenNMS again, but the other options I think might
> work are Icinga (Should be trivial to migrate) or Zenoss or maybe even Zabbix?
>
> Anyone have experience in Nagios and care to share comparisons with similar
> projects with strong community involvement?
>
> Also, anyone currently running OpenNMS that can comment on the learning curve
> and level of flexibility coming from a Nagios user?

It depends on what you are doing, but if it is mostly snmp data 
collection and icmp/tcp application monitoring, OpenNMS will probably do 
it out of the box with autodiscovery and no client setup.  If you have 
lots of custom nagios client code, you'll probably have to twiddle some 
ugly XML config files to get that data collected.  The mail list support 
is fairly good if you have problems.

-- 
   Les Mikesell
lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] 5.5 & gspca

[JohnS]

On Fri, 2010-06-18 at 11:34 -0400, m.r...@5-cent.us wrote:

> Um, what's kernel-rt got to do with anything I said? And actually, the
> first server I'm trying to build this on is a Sunfire, but it's running
> Opterons, and the o/s is 64-bit. I also do *not* have any xen installed.
> 
> Fine, I tried running
>  rpmbuild -ba --target=x86_64 --without xen video4linux-kmod.spec
> Building target platforms: x86_64
> Building for target x86_64
> error: Failed build dependencies:
> kernel-xen-devel-x86_64 = 2.6.18-194.3.1.el5 is needed by
> video4linux-kmod-0.0-5.20090615.el5.elrepo.x86_64
> 
> My last trick was to edit the stupid spec file, and comment out
> #%ifarch i686 x86_64
> #%define xenvar xen
> #%endif
> and it *still* wants to build for xen.
> 
> No, the rpmbuild is not correct. So, back to the original, of trying to
> figure out just what kernel modules I need to install, rather than the
> laundry list it correctly builds when I drop the rpm, and build from the
> blown-out tarfile.
---
Wrong the rpm build will *WORK* I promise it will if done correct with
out the other cruft..  You did not read the rest of the threads?  Ned
showed how to do it the right way.

rpmbuild -ba  --target=i686 --define 'kvariants "put kvariant_here"'
video4linux-kmod.spec

knownvariants=@(BOOT|PAE|@(big|huge)mem|debug|enterprise|kdump|? \
(large)smp|uml| xen[0U]?(-PAE)|xen)

--target=x86_64  if you have 64 bit..  

And it works on the main CentOS Kernel also this way,,,just tried it for
the hell of it.

And you ask what does kernel-rt have to do with it?  Read the posts with
the disclaimer.

John


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recognizing correct number of cores on CPU

[Jerry Geis]

All,

I booted with 2.6.18 kernel with only "noapic acpi=off" I removed the 
apci=off
and the kernel still dumps with a bunch of messages about acpi.

I have installed 2.6.34 kernel on the box.
I can boot without the acpi=off and I get all 4 cores on this box.

if I put in the acpi=off it only reports one core in /proc/cpuinfo

Jerry
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Upgrade

[tony . chamberlain]

I am currently running CentOS 4.5 (which, through many Yum updates) now appears 
to be CentOD 4.8.

4.8 is still rather old, but I havbe lots of stuff (files and stuff installed). 
I would like to install Fedora but I am worried about losing
all the stuff I have. I would have to back everything up, uninstall/reinstall
things, etc. I am wondering whether there is some way to upgrade to Fedora 
from CentOS without just having to reinstall everything?

- Done.




___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrade

[Robert Heller]

At Fri, 18 Jun 2010 16:26:08 + CentOS mailing list  
wrote:

> 
> 
> 
> I am currently running CentOS 4.5 (which, through many Yum updates) now 
> appears to be CentOD 4.8.
> 
> 4.8 is still rather old, but I havbe lots of stuff (files and stuff 
> installed). I would like to install Fedora but I am worried about losing
> all the stuff I have. I would have to back everything up, uninstall/reinstall
> things, etc. I am wondering whether there is some way to upgrade to Fedora 
> from CentOS without just having to reinstall everything?

You really *should* back everything up and do a fresh install of Fedora
(or CentOS 5.5), then re-install your extra packages.  You really don't
want to upgrade in place, unless you really, really, know what you are
doing and/or are willing to live with various (subtle) problems caused
by possibly incompatible 'leftover' packages.

Hint: Having a separate file system for /home is a *good* thing.  Having
/usr/local on a separate file system also is gravey on the side... (for
web servers /var/www, for mail servers /var/spool/mail, etc.).

> 
> - Done.
> 
> 
> 
> 
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
> 
>   
> 

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Download the Model Railroad System
http://www.deepsoft.com/  -- Binaries for Linux and MS-Windows
hel...@deepsoft.com   -- http://www.deepsoft.com/ModelRailroadSystem/
 
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrade

[Brian Mathis]

On Fri, Jun 18, 2010 at 12:26 PM,   wrote:
>
> I am currently running CentOS 4.5 (which, through many Yum updates) now 
> appears to be CentOD 4.8.
>
> 4.8 is still rather old, but I havbe lots of stuff (files and stuff 
> installed). I would like to install Fedora but I am worried about losing
> all the stuff I have. I would have to back everything up, uninstall/reinstall
> things, etc. I am wondering whether there is some way to upgrade to Fedora
> from CentOS without just having to reinstall everything?
>
> - Done.


It's a bad idea to "upgrade" through major versions without doing a
full reinstall.  Also, going from Centos 4 to Fedora is very strange
as Fedora is not meant for servers.  You really should be using a
Server OS (Like CentOS 5) instead of Fedora.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Migrating away from Nagios

[Joseph L. Casale]

>I am a pretty hardcore ZenOSS user.. We use it to monitor over 1000
>devices in different fashions - using a combination of SNMP (Linux), WMI
>(windows) and SSH (Unix/Aix).  While there is a slight learning curve to
>get everything working the way you want - it is, in my opinion, the most
>powerful open source NMS.  It is a very active project with excellent
>community (and even commercial) support.

Yeah, the WMI capability is a big plus for me...
I am downloading the pdf's to print for some weekend reading.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Migrating away from Nagios

[Joseph L. Casale]

>It depends on what you are doing, but if it is mostly snmp data 
>collection and icmp/tcp application monitoring, OpenNMS will probably do 
>it out of the box with autodiscovery and no client setup.  If you have 
>lots of custom nagios client code, you'll probably have to twiddle some 
>ugly XML config files to get that data collected.  The mail list support 
>is fairly good if you have problems.

Les,
Compared to Nagios, how difficult was it to get OpenNMS running in your
environment? I found Nagios trivial but have never really rolled my sleeves
up with OpenNMS, I have just sort of kicked the tires over the years...

I have to say the WMI capability of Zenoss is a real plus for me and the
documentation  for Zenoss looks way better than OpenNMS which even they
admit on the wiki isn't very good:)

jlc
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrade

[m . roth]

tony.chamberl...@lemko.com wrote:
>
> I am currently running CentOS 4.5 (which, through many Yum updates) now
> appears to be CentOD 4.8.
>
> 4.8 is still rather old, but I havbe lots of stuff (files and stuff
> installed). I would like to install Fedora but I am worried about losing
> all the stuff I have. I would have to back everything up,
> uninstall/reinstall
> things, etc. I am wondering whether there is some way to upgrade to Fedora
> from CentOS without just having to reinstall everything?
>

I wrote an article that was published in SysAdmin, before it went under.


And as others have said, /home, and maybe /opt, should *always* be other
drives, or at least other partitions

  mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Migrating away from Nagios

[Les Mikesell]

On 6/18/2010 12:06 PM, Joseph L. Casale wrote:
>> It depends on what you are doing, but if it is mostly snmp data
>> collection and icmp/tcp application monitoring, OpenNMS will probably do
>> it out of the box with autodiscovery and no client setup.  If you have
>> lots of custom nagios client code, you'll probably have to twiddle some
>> ugly XML config files to get that data collected.  The mail list support
>> is fairly good if you have problems.
>
> Les,
> Compared to Nagios, how difficult was it to get OpenNMS running in your
> environment? I found Nagios trivial but have never really rolled my sleeves
> up with OpenNMS, I have just sort of kicked the tires over the years...

I've never done Nagios - I don't want to think about anything that needs 
per-host configuration and I want to get router/switch/link details in 
the same tool.   'Getting it running'  should be a yum install these 
days plus configuring a discovery range which you can now do through the 
web interface.  If you have a server for a test install and the same 
snmp community string everywhere it should be painless to test.

The one thing I find a bit cumbersome is building pages with the graph 
groupings that I want to see together.  It's not a difficult process, 
just several steps to pick and position each one on a page.   But that's 
just for convenience - you can go to the node page and pick graphs 
individually without this.

> I have to say the WMI capability of Zenoss is a real plus for me and the
> documentation  for Zenoss looks way better than OpenNMS which even they
> admit on the wiki isn't very good:)

I tried WMI on opennms a while back and couldn't make it work, but I'm 
sure it is much better now.  As for documentation in general, you 
shouldn't need much to get started and the mail list is pretty good if 
you have specific questions.  In fact I usually look at mail list 
archives before making choices like this.  If people are asking about 
problems with the basic application functionality I'm less likely to try 
it than if the discussions are about adding new stuff or extensions.

-- 
   Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[John R. Dennison]

On Fri, Jun 18, 2010 at 08:14:02AM -0400, Whit Blauvelt wrote:
> 
> Why yes, John, it is. The fine man said outright he didn't believe my honest
> account, accusing me of making something up when I was only giving the
> facts. He was calling me a liar. He preferred to see my account as a lie so
> as not to surrender his faith that Ganglia is a pure and perfect project.
> Attitudes like that are dangerous in computing, since they lead to bugs not
> being fixed.

While KBS could have very well chosen his wording differently
he did not call you a liar.  That is the interpretation you
choose to apply to what he said.  If someone tells me that it's
going to rain, and I see nothing but blue skies on the horizon
and tell them I don't believe them I am not calling them a
liar; I am, however, telling them that they are wrong.  By
this account I find your use of "ignorant" rude and uncalled
for.

> You installed without a conflict, good. Perhaps you were installing on a
> 32-bit system rather than a 64-bit? Perhaps your system didn't have some of
> the packages already installed for other functionality that mine did? All I
> can say is that, for my system, yum saw version conflicts that were
> blockers.

Yep, 32-bit.  As you didn't point out whether you attempted the
32-bit or 64-bit version I grabbed a test box at random and it 
happened to be 32-bit.  

As far as conflicts go I will say again, I didn't have any.  And
without further evidence from you there's no way to determine
why you are reporting alleged conflicts, nor what those
conflicts may be.  If there are conflicts it's it is much more
likely that they stem from self-installs or poorly chosen
3rd party repos then they do with EPEL.

> As for "properly," there are, as Larry Wall says, many ways to do it. It is
> up to each project, as their first task, IMHO, to see to it that
> ./configure, make, make install works for their package, with proper,
> documented flags, on standard Linux distros. Ganglia - a fine and valuable
> project on the whole - has a broken "make install." But it can be worked
> around. Finding workarounds is often a sysadmins job. Sharing those
> workarounds with the community is often how free software stays ahead of the
> proprietary stuff. 

This doesn't carry much weight with me when we are talking about
an enterprise distro unless the problems are discovered in the
process of building SRPMs.

By the way, did you report this issue upstream and offer them
the workarounds in the form of patches?

> On the whole, this list is professional. I like that. But look,
> "./configure, make, make install" is _always_ a proper option. Any serious

No, it's not.

> business will have need of building on occassional program with different
> flags than the distro's default, whatever the distro. I often end up

And those needs are best met by rolling SRPMs.  Heck, you could
even give back to the community and make them available for
others to make use of.

> building a few core applications that way, as do many other sysadmins in
> serious business settings. If you don't need to, that's fine. Some
> businesses can wear off-the-rack cloths. Others need tailored garments.

I don't dispute this at all; it's very true and will remain
true.

My argument is that building native tarballs and then installing
them is *not* the way to go when you are working with a package
managed system such as CentOS; take the additional time and make
SRPMs that can be properly integrated into the package system.
The benefits from such can not be understated and are *well*
worth your time.  You're not new to the industry so I'm a little
confused as to why you don't see this.




John
-- 
A nuclear war does not defend a country and it does not defend a system.
I've put it the same way many times; not even the most accomplished
ideologue will be able to tell the difference between the ashes of
capitalism and the ashes of communism.

-- John Kenneth Galbraith (1908 - 2006), Canadian-American economist and
author, The Ashes of Capitalism and the Ashes of Communism, interview
with John M.  Whiteley in Quest for Peace: an Introduction (1986)


pgpU7FryXu2Br.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[John R. Dennison]

On Fri, Jun 18, 2010 at 08:25:56AM -0400, Whit Blauvelt wrote:
> 
> To get 3.1.7? Disregarding that, I should jump through the hoops of
> recompiling a F13 RPM rather than just compile from the tar? Why? Every
> extra stage like that introduces the chance of incidental errors, of stuff
> that doesn't translate precisely through that stage. I'm not doubting it
> generally can work, just that there's anything "proper" about it. Generally
> native source is the gold standard. The farther upstream you go, the better
> the quality gets, the more bugs are fixed, and the more control you have
> over how and where the stuff installs on your systems. 

You really believe this?  If so, why do you bother with CentOS,
or any package managed distro?  Native builds are *never* the
way to go, but I quite refuse to waste my time pointing out the
many drawbacks of such compared to taking a few moments to
properly - yes, *properly* - make SRPMs and and rebuilding
*those* on the target platforms.

The "gold standard" is that procedure, not building source kits
that can, and *will* walk all over the rest of your system.
Just because it may not have happened yet is nothing but pure
luck.

> There can be an argument that for some stuff that passes through RHEL the
> extra attention adds some quality control (ignoring the counterexample of
> the long history of RH manging kernels; they seem to have gotten better
> about that lately), but stuff in EPEL? Really?

Some quality control?  Really?  I can see this discussion is
going no where and you have your mind made up.  





John
-- 
He may be mad, but there's method in his madness.  There nearly always is
method in madness.  It's what drives men mad, being methodical.

-- G. K. Chesterton, The Fad of the Fisherman (1922)


pgpaaZ0FVce4m.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrade

[Whit Blauvelt]

On Fri, Jun 18, 2010 at 02:29:32PM -0400, m.r...@5-cent.us wrote:

> And as others have said, /home, and maybe /opt, should *always* be other
> drives, or at least other partitions

Kind of makes you wonder why RH's default install is to shove everything but
boot into one partition these days, doesn't it? In trying to make everything
immune from the most clueless users - who might (horrors) make a partition
too small - RH defaults to something other than time-honored old-school best
practices. Yeah, I never accept the defaults. But I'm not the only guy who
ever installs RH or CentOS in my shop, and getting everyone else up to speed
on this sort of thing only annoys 'em. They tend to take it on faith that
the defaults are sane. They should at least come with a warning label: "This
is our default, but if you know what you're doing, you really should
override."

Regards,
Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrade

[m . roth]

Whit Blauvelt wrote:
> On Fri, Jun 18, 2010 at 02:29:32PM -0400, m.r...@5-cent.us wrote:
>
>> And as others have said, /home, and maybe /opt, should *always* be other
>> drives, or at least other partitions
>
> Kind of makes you wonder why RH's default install is to shove everything
> but boot into one partition these days, doesn't it? In trying to make
> everything immune from the most clueless users - who might (horrors) make
> a partition too small - RH defaults to something other than time-honored
> old-school best practices. Yeah, I never accept the defaults. But I'm not

Very, dare I say it?, Windows-ish. On the other hand, for an enterprise
O/S, I would sorta-kinda assume that /home was being NFS-mounted. Just
about everywhere I've worked, it is.

  mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[John R. Dennison]

On Fri, Jun 18, 2010 at 08:41:26AM -0400, Whit Blauvelt wrote:
> 
> Now you're threatening to expel me from the community? For posting notes on
> workarounds to get a useful package to work? What's this about? Ganglia's
> working fine for me.

I'm honored that you think I have that much sway in this
community that I would be able to expel you from it.  The
reality, however, is quite different.  I don't speak for the
project, nor do I speak for the community as a whole; I have
enough difficulty speaking for myself.

My issues were your building from native source doing the
standard three-step; it's wrong to do so in an rpm-managed
distro.  

> My claims? The project's own documents describe this stuff. You saw no
> conflicts? Great. Not every bug shows up on every box. You believe one
> instance of not seeing a bug means no on else will? That's Microsoft-style
> quality control.

Yes, *claims*.  You've provided no evidence except your claims
that it didn't work.  And please understand that I said it
worked *for me* and that *I* didn't see a conflict.  I never
said it wasn't an issue for others.  Had I noticed a problem I'd
also have taken the time to document such to the parties
responsible, including this mailing list.

> Sorry. If that's confusion, I got it from instructions (several sets of
> them) out on the web for installing Ganglia from EPEL, which referred to it
> as a Fedora repository. 

Yep, confusion.  You do, I hope, realize that EL and the
offspring of EL including CentOS are based on Fedora?  This
makes Fedora the test base for future EL cuts.  EPEL is just a
3rd party repo providing (mostly) Fedora kit rebuilt for EL use
in CentOS, SL, etc.

> I said I've been a Linux sysadmin since '93. I've been in the industry since
> '82. Thanks for mistaking me for a youngster though!

That's nice.  With an illustrious background such as yours I'd
expect less argument over the merits of SRPMs vs native builds
and a better understanding of EPEL's role.



John

-- 
Most people hate the idea of evolution because they realize that if it were
working properly, they'd be dead.

-- Anonymous


pgpXlCUvcu0D8.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[John R Pierce]

John R. Dennison wrote:
>
>> On the whole, this list is professional. I like that. But look,
>> "./configure, make, make install" is _always_ a proper option. Any serious
>> 
>
>   No, it's not.
>   

indeed, doing exactly this could very well lead to the conflicts he 
reported when he tried to install ganglia from EPEL.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[John R. Dennison]

On Fri, Jun 18, 2010 at 10:01:38AM -0400, Whit Blauvelt wrote:
> 
> "Extra Packages for Enterprise Linux (EPEL) is a volunteer-based community
> effort from the Fedora project to create a repository of high-quality add-on
> ..."
> 
> Enough said.

Apparently not as that bears no indication of it being a test
base as your initial claim stated.




John

-- 
We must respect the other fellow's religion, but only in the same sense and
to the extent that we respect his theory that his wife is beautiful and his
children smart.

-- H. L. Mencken (1880-1956), writer, editor, and critic


pgpWRiSBxPsru.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] free ftp server

[John R Pierce]

MOKRANI Rachid wrote:
> Any idea about a software we can use in our local server ?
>   

I've used dokuwiki for this, where I've restricted the access to the 
wiki pages to registered users whom are in the appropriate user 
groups.   the persons sending the files upload them as wiki attachments, 
use the wiki page itself to explain what the file is, then the other 
parties can download them from the wiki.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[m . roth]

John R. Dennison wrote:
> On Fri, Jun 18, 2010 at 08:41:26AM -0400, Whit Blauvelt wrote:

>   My issues were your building from native source doing the
>   standard three-step; it's wrong to do so in an rpm-managed
>   distro.
>
Up until now, I had to build the gspca driver separately, every time I
upgraded those servers with the cameras attached. I also *always* have to
do something - mostly reinstall - when I upgrade the boxes, mostly older,
with nvidia drivers. (And let's not talk about the newest upgrade to FC
13, which has none)

Even such a large install as CentOS/RHEL can't cover all hardware.

  mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrade

[Rob Kampen]

m.r...@5-cent.us wrote:

  Whit Blauvelt wrote:
  
  
On Fri, Jun 18, 2010 at 02:29:32PM -0400, m.r...@5-cent.us wrote:



  And as others have said, /home, and maybe /opt, should *always* be other
drives, or at least other partitions
  

Kind of makes you wonder why RH's default install is to shove everything
but boot into one partition these days, doesn't it? In trying to make
everything immune from the most clueless users - who might (horrors) make
a partition too small - RH defaults to something other than time-honored
old-school best practices. Yeah, I never accept the defaults. But I'm not

  
  
Very, dare I say it?, Windows-ish. On the other hand, for an enterprise
O/S, I would sorta-kinda assume that /home was being NFS-mounted. Just
about everywhere I've worked, it is.

  

Not trying to hijack but this last comment has provoked a question.

If you have multiple CentOS machines that you regularly log onto and
use, and these share a common /home/username (via NFS or other SAN
mechanism) how do the various . files manage to work - aren't there
potential conflicts?
I have two CentOS 5.5 workstations with dual monitors (different sizes
though) and another machine with only a single display - wouldn't this
cause issues? Unfortunately I do not have enough experience to know
what all these various . files contain - if they're only personal
preferences and totally unrelated to the hardware then well and good -
can someone confirm before I migrate my /home onto my main server and
NFS mount it. TIA


mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
  



<>___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[John R. Dennison]

On Fri, Jun 18, 2010 at 03:15:41PM -0400, m.r...@5-cent.us wrote:
>
> Up until now, I had to build the gspca driver separately, every time I
> upgraded those servers with the cameras attached. I also *always* have to
> do something - mostly reinstall - when I upgrade the boxes, mostly older,
> with nvidia drivers. (And let's not talk about the newest upgrade to FC
> 13, which has none)

And what is the problem with the dkms-gspca stuff at rpmforge?

> Even such a large install as CentOS/RHEL can't cover all hardware.

Nor should it have to.  There exist vetted 3rd-party repos
that provide support for much that EL does not.





John

-- 
The Earth is a very small stage in a vast cosmic arena.  Think of the
rivers of blood spilled by all those generals and emperors so that, in
glory and triumph, they could become the momentary masters of a fraction of
a dot.  Think of the endless cruelties visited by the inhabitants of one
corner of this pixel on the scarcely distinguishable inhabitants of some
other corner, how frequent their misunderstandings, how eager they are to
kill one another, how fervent their hatreds.

-- Carl Sagan (1934-1996), astronomer and writer


pgpphF5Xq1DvH.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrade

[Les Mikesell]

On 6/18/2010 2:05 PM, m.r...@5-cent.us wrote:
> Whit Blauvelt wrote:
>> On Fri, Jun 18, 2010 at 02:29:32PM -0400, m.r...@5-cent.us wrote:
>>
>>> And as others have said, /home, and maybe /opt, should *always* be other
>>> drives, or at least other partitions
>>
>> Kind of makes you wonder why RH's default install is to shove everything
>> but boot into one partition these days, doesn't it? In trying to make
>> everything immune from the most clueless users - who might (horrors) make
>> a partition too small - RH defaults to something other than time-honored
>> old-school best practices. Yeah, I never accept the defaults. But I'm not
>
> Very, dare I say it?, Windows-ish. On the other hand, for an enterprise
> O/S, I would sorta-kinda assume that /home was being NFS-mounted. Just
> about everywhere I've worked, it is.
> 

The piece I've always wanted was for the installer to be able to install 
on raid1 by default or even a 'broken' raid1 where you could add and 
sync the matching mirror later.  SME server added this feature.

-- 
   Les Mikesell
lesmikes...@gmail.com

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] amazon ec2 and centos?

[Johnny Tan]

On 06/11/2010 02:17 PM, Karanbir Singh wrote:
> Ok, so since there is some level of interest and a few people have
> offered to test, let me get something together and post some details

Our AWS technical reps stopped by our office the other day. They
said the primary issue with CentOS in terms of the AKI/ARI is that
the creation process is tedious, not straightforwad, and they
usually only open that up to "partners" who will sign an NDA. And
they are more used to working with business entities, such as Red
Hat, Oracle, etc. Maybe they're confused as to what to do with
"CentOS"? I don't know.

But since we have a business relation with them already and are
under NDA, we did tell them we were happy to develop the proper
AKI/ARIs and give those to CentOS to vet. So they will send us the
API to do so, shortly.

This might all be moot, as there are changes coming to AWS soon in
relation to this (among many other things), but we'll wait to see
what's publicly announced.

johnny
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrade

[Ron Loftin]

On Fri, 2010-06-18 at 15:17 -0400, Rob Kampen wrote:
> m.r...@5-cent.us wrote: 
> > Whit Blauvelt wrote:
> >   
> > > On Fri, Jun 18, 2010 at 02:29:32PM -0400, m.r...@5-cent.us wrote:
> > > 
> > > 
> > > > And as others have said, /home, and maybe /opt, should *always* be other
> > > > drives, or at least other partitions
> > > >   
> > > Kind of makes you wonder why RH's default install is to shove everything
> > > but boot into one partition these days, doesn't it? In trying to make
> > > everything immune from the most clueless users - who might (horrors) make
> > > a partition too small - RH defaults to something other than time-honored
> > > old-school best practices. Yeah, I never accept the defaults. But I'm not
> > > 
> > 
> > Very, dare I say it?, Windows-ish. On the other hand, for an enterprise
> > O/S, I would sorta-kinda assume that /home was being NFS-mounted. Just
> > about everywhere I've worked, it is.
> > 
> >   
> Not trying to hijack but this last comment has provoked a question.
> 
> If you have multiple CentOS machines that you regularly log onto and
> use, and these share a common /home/username (via NFS or other SAN
> mechanism) how do the various . files manage to work - aren't
> there potential conflicts?
> I have two CentOS 5.5 workstations with dual monitors (different sizes
> though) and another machine with only a single display - wouldn't this
> cause issues? Unfortunately I do not have enough experience to know
> what all these various . files contain - if they're only personal
> preferences and totally unrelated to the hardware then well and good -
> can someone confirm before I migrate my /home onto my main server and
> NFS mount it. TIA

I have multiple machine that share /home via NFS.  Some have dual
displays and some don't.  The "normal" behavior for me is that the
single-head boxes just ignore the configuration for the second display.
Otherwise they all run the same.  Note that these are all CentOS 5
machines that get updates applied pretty much all at the same time.

As always, YMMV. ;>

> 
> > mark
> > 
> > ___
> > CentOS mailing list
> > CentOS@centos.org
> > http://lists.centos.org/mailman/listinfo/centos
> >   
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
-- 
Ron Loftin  relof...@twcny.rr.com

"God, root, what is difference ?"   Piter from UserFriendly

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] amazon ec2 and centos?

[Karanbir Singh]

On 18/06/2010 20:25, Johnny Tan wrote:
> But since we have a business relation with them already and are
> under NDA, we did tell them we were happy to develop the proper
> AKI/ARIs and give those to CentOS to vet. So they will send us the
> API to do so, shortly.

Please dont communicate to them or anyone else that the CentOS project
or people representing it will agree to be bound under any NDA that they
didnt sign themselves. And certainly not when done by proxy.

Not being awkward here, but I'm not going to accept any such thing when
it does not involve me directly and I am fairly certain that this would
extend to all the other CentOS developers as well.

If you can and are willing to, asking those people at AWS to ping the
guys talking with us would be a good step to take instead.

- KB
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] amazon ec2 and centos?

[R P Herrold]

On Fri, 18 Jun 2010, Karanbir Singh wrote:

> Not being awkward here, but I'm not going to accept any such thing when
> it does not involve me directly and I am fairly certain that this would
> extend to all the other CentOS developers as well.

heartily concur; I manage the NDAs to which I am even arguably 
subject quite closely, and in this part of FOSS space, there 
is 'no way, no how' I will or would so assent

I was wondering how we would handle a 'blob' handed to us for 
review by a third party

--- Russ herrold
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] 5.5 & gspca

[Ned Slider]

On 18/06/10 16:34, m.r...@5-cent.us wrote:
>
> Fine, I tried running
>   rpmbuild -ba --target=x86_64 --without xen video4linux-kmod.spec


Go back and read my last reply, or read the SPEC file again.

If you don't want to build for xen then you must define kvariants on the 
rpmbuild command line for the variants you do want to build for. As you 
only want the plain kernel, you must define kvariants as null:

rpmbuild -ba  --target=x86_64 --define 'kvariants ""' video4linux-kmod.spec

Alternatively, try with the latest src.rpm, which isn't compatible with 
xen kernels so support for xen has been removed (much as you tried to do):

http://elrepo.org/linux/testing/el5/SRPMS/video4linux-kmod-0.0-7.20100410.el5.elrepo.src.rpm

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] the Postfix packages are way too old

[Florin Andrei]

If you deliver more than a few emails to the outside world, especially 
if a good portion of those go to Yahoo, you may want to read this message:

http://marc.info/?l=postfix-users&m=127689518629249&w=2

Actually, read the whole thread, it's interesting and the discussion 
still continues:

http://marc.info/?t=12761961161&r=1&w=2

TLDR: The 2.3.3 Postfix version that comes with RH / CentOS 5 doesn't do 
delivery rate control very well and has a habit of annoying some email 
providers. A simple upgrade from 2.3.3 to 2.7.0, no config changes, can 
improve delivery rate by 50% in some cases (e.g. if you deliver 
thousands of emails to Yahoo). With config changes, the improvement 
might be even bigger.

Fun fact: Postfix-2.3.3 has been released in August 2006. Think about that.

-- 
Florin Andrei
http://florin.myip.org/
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] amazon ec2 and centos?

[Johnny Tan]

On 06/18/2010 04:55 PM, Karanbir Singh wrote:
> Please dont communicate to them or anyone else that the CentOS project
> or people representing it will agree to be bound under any NDA that they
> didnt sign themselves. And certainly not when done by proxy.

This was definitely not what we communicated nor the impression they
got.

As they see it, we are just developing an AKI on our own. Only from
our point of view would we submit to CentOS for review.


> Not being awkward here, but I'm not going to accept any such thing when
> it does not involve me directly and I am fairly certain that this would
> extend to all the other CentOS developers as well.

Makes sense. In that case, we'll develop for our use only, and offer
advice if asked.


> If you can and are willing to, asking those people at AWS to ping the
> guys talking with us would be a good step to take instead.

Do you have a name? I'm more than happy to have our reps prod your reps.

johnny
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] the Postfix packages are way too old

[Whit Blauvelt]

On Fri, Jun 18, 2010 at 02:28:36PM -0700, Florin Andrei wrote:

> Fun fact: Postfix-2.3.3 has been released in August 2006. Think about that.

To be fair, RH/CentOS also ships with Sendmail-8.13.8, also from August 2006. 
What
a golden month for mail daemons that was.

The door's wide open for someone with the energy to put together a server
distro based on CentOS but with modern versions of essential daemons. Yes,
it wouldn't inherit certification from commercial software vendors who now
spec RH/CentOS. But major daemons like Postfix and Sendmail are very well
tested in tens of thousands of deployments in versions not over a year old
(which are significantly superior to versions from 2006, no matter how much
backporting of new features RH might have done meanwhile). They should be
stock in any current distro.

It used to be that RH's advantage was its daemons weren't as crufty as
Debian stable. But now with Ubuntu's server version solid - not nearly as
well supported by the user community as CentOS, but quite current in its
major daemon versions - those who want there to be good, widely used distros
in the RH mold five years out from now would do well to push ahead of RH in
the server space. Some sort of a CentOS+, unbound from RH's laggard ways,
but conservative in its stability, could find itself quite welcome in the
world.

Is anyone working on this? (No, not Fedora. That's not a server OS.)

Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] the Postfix packages are way too old

[Florin Andrei]

On 06/18/2010 03:02 PM, Whit Blauvelt wrote:
>
> To be fair, RH/CentOS also ships with Sendmail-8.13.8, also from August 2006. 
> What
> a golden month for mail daemons that was.

lol

> The door's wide open for someone with the energy to put together a server
> distro based on CentOS but with modern versions of essential daemons.

Nah. That's like killing a flea with the jackhammer. You don't often 
need *all* daemons to be up-to-date on any given system - and when you 
do, that's usually a tiny machine, like my personal mail/web server, in 
which case you can deal with the upgrades on a case-by-case basis.

Just "rpm -U" the 2.7 package and that's it. For a mail relay, the rest 
is good.

-- 
Florin Andrei
http://florin.myip.org/
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] the Postfix packages are way too old

[Les Mikesell]

On 6/18/2010 5:02 PM, Whit Blauvelt wrote:
>
>> Fun fact: Postfix-2.3.3 has been released in August 2006. Think about that.
>
> To be fair, RH/CentOS also ships with Sendmail-8.13.8, also from August 2006. 
> What
> a golden month for mail daemons that was.
>
> The door's wide open for someone with the energy to put together a server
> distro based on CentOS but with modern versions of essential daemons. Yes,
> it wouldn't inherit certification from commercial software vendors who now
> spec RH/CentOS. But major daemons like Postfix and Sendmail are very well
> tested in tens of thousands of deployments in versions not over a year old
> (which are significantly superior to versions from 2006, no matter how much
> backporting of new features RH might have done meanwhile). They should be
> stock in any current distro.
>
> It used to be that RH's advantage was its daemons weren't as crufty as
> Debian stable. But now with Ubuntu's server version solid - not nearly as
> well supported by the user community as CentOS, but quite current in its
> major daemon versions - those who want there to be good, widely used distros
> in the RH mold five years out from now would do well to push ahead of RH in
> the server space. Some sort of a CentOS+, unbound from RH's laggard ways,
> but conservative in its stability, could find itself quite welcome in the
> world.
>
> Is anyone working on this? (No, not Fedora. That's not a server OS.)

I agree with the sentiment of wanting something with a well-tested 
kernel and base lib set and fairly current apps, but you do know that 
RHEL6 beta is out now don't you?  It has been a while but you wouldn't 
have wanted anything based on the intermediate Fedora versions.  So it's 
probably not the time to start thinking about building something else. 
And the LTS versions of Ubuntu would probably be the place to jump if 
you are looking for current alternatives.

-- 
Les Mikesell
  lesmikes...@gmail.com


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] the Postfix packages are way too old

[John R Pierce]

Whit Blauvelt wrote:
> On Fri, Jun 18, 2010 at 02:28:36PM -0700, Florin Andrei wrote:
>
>   
>> Fun fact: Postfix-2.3.3 has been released in August 2006. Think about that.
>> 
>
> To be fair, RH/CentOS also ships with Sendmail-8.13.8, also from August 2006. 
> What
> a golden month for mail daemons that was.
>   

and in fact, EL5's beta started in September 2006, it was released in 
early 2007.  We're overdue for a major new release, I think.

> ...
> It used to be that RH's advantage was its daemons weren't as crufty as
> Debian stable. But now with Ubuntu's server version solid - not nearly as
> well supported by the user community as CentOS, but quite current in its
> major daemon versions - those who want there to be good, widely used distros
> in the RH mold five years out from now would do well to push ahead of RH in
> the server space. Some sort of a CentOS+, unbound from RH's laggard ways,
> but conservative in its stability, could find itself quite welcome in the
> world.
>
> Is anyone working on this? (No, not Fedora. That's not a server OS.)
>   

isn't EL6 coming out soon ?   beta 1 released in April,  if they follow 
the same schedule as EL5, beta 2 is should be along pretty soon, and 
release would likely follow about 4 months later, which I'd estimate to 
be in the October time frame...


(reading the EL6 beta 1 release notes) EL6 will be based on 2.6.32, use 
EXT4 by default, have XFS support (in 64bit builds), Apache 2.2.14, gcc 
4.4, samba 3.0, postgres 8.4, mysql 5.1.  LVM now supports mirrors, so 
you can dodge the added complexities of using mdraid under lvm.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] the Postfix packages are way too old

[Florin Andrei]

On 06/18/2010 03:19 PM, John R Pierce wrote:
>
> (reading the EL6 beta 1 release notes) EL6 will be based on 2.6.32, use
> EXT4 by default, have XFS support (in 64bit builds), Apache 2.2.14, gcc
> 4.4, samba 3.0, postgres 8.4, mysql 5.1

and Postfix 2.6.5. Not bad. I could live with that.

-- 
Florin Andrei
http://florin.myip.org/
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] the Postfix packages are way too old

[Stephen Harris]

On Fri, Jun 18, 2010 at 06:02:10PM -0400, Whit Blauvelt wrote:
> The door's wide open for someone with the energy to put together a server
> distro based on CentOS but with modern versions of essential daemons. Yes,

Or wait for RedHat^WCentOS 6, which can't be too far out...

RHEL 2.1: Mar 2002 (AS), May 2003 (ES)
RHEL 3: Oct 2003
RHEL 4: Feb 2005
RHEL 5: Mar 2007
RHEL 6: ???  (previous Beta's have been 5-6 months...)

Funky; in June 2006 RHEL claimed they would slow their release schedule to
every 2 years (rather than 18 months).  Oops!  They didn't make that :-)

http://www.computerworld.com/s/article/9000903/Red_Hat_slows_down_release_schedule_to_accommodate_customers

-- 

rgds
Stephen
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] the Postfix packages are way too old

[John R Pierce]

Stephen Harris wrote:
> RHEL 2.1: Mar 2002 (AS), May 2003 (ES)
> RHEL 3: Oct 2003
> RHEL 4: Feb 2005
> RHEL 5: Mar 2007
> RHEL 6: ???  (previous Beta's have been 5-6 months...)
>
> Funky; in June 2006 RHEL claimed they would slow their release schedule to
> every 2 years (rather than 18 months).  Oops!  They didn't make that :-)
>   

I bet they realized that even 2 years, with a 7 year life cycle, they'd 
be supporting 3-4 major versions concurrently.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] the Postfix packages are way too old

[Athmane Madjoudj]

>
> Is anyone working on this? (No, not Fedora. That's not a server OS.)
>

When i find some package "old" i just get the SRPM from Fedora and i try 
to compile it in CentOS (it's very fun!)

although CentOS/RHEL packages seems to be old, RH folks back-port 
security / bugfix patches


I use fedora in my laptop it almost very stable, for no critical server 
fedora is good also if yum preupgrade will be well supported then fedora 
for server will be better (you have 1y of update before preupgrade)


Best regards.

-- 
Athmane Madjoudj
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] the Postfix packages are way too old

[Paul Heinlein]

On Fri, 18 Jun 2010, Florin Andrei wrote:

> On 06/18/2010 03:19 PM, John R Pierce wrote:
>>
>> (reading the EL6 beta 1 release notes) EL6 will be based on 2.6.32, 
>> use EXT4 by default, have XFS support (in 64bit builds), Apache 
>> 2.2.14, gcc 4.4, samba 3.0, postgres 8.4, mysql 5.1
>
> and Postfix 2.6.5. Not bad. I could live with that.

In my one and only RHEL 6b1 installation, Postfix was the default MTA. 
I suspect that will be true with the final release as well, though 
sendmail 8.14.3 is also available.

-- 
Paul Heinlein <> heinl...@madboa.com <> http://www.madboa.com/
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrade

[Robert Heller]

At Fri, 18 Jun 2010 15:17:22 -0400 CentOS mailing list  
wrote:

> 
> 
> 
> 
> 
>   
> 
> 
>  href="mailto:m.r...@5-cent.us";>m.r...@5-cent.us wrote:
>   cite="mid:40c4699fc9f09a3b67e6c69636e41b14.squir...@host290.hostmonster.com"
>  type="cite">
>   Whit Blauvelt wrote:
>   
>   
> On Fri, Jun 18, 2010 at 02:29:32PM -0400,  class="moz-txt-link-abbreviated" 
> href="mailto:m.r...@5-cent.us";>m.r...@5-cent.us wrote:
> 
> 
> 
>   And as others have said, /home, and maybe /opt, should 
> *always* be other
> drives, or at least other partitions
>   
> 
> Kind of makes you wonder why RH's default install is to 
> shove everything
> but boot into one partition these days, doesn't it? In trying to make
> everything immune from the most clueless users - who might (horrors) make
> a partition too small - RH defaults to something other than time-honored
> old-school best practices. Yeah, I never accept the defaults. But I'm not
> 
>   
>   
> Very, dare I say it?, Windows-ish. On the other hand, for an enterprise
> O/S, I would sorta-kinda assume that /home was being NFS-mounted. Just
> about everywhere I've worked, it is.
> 
>   
> 
> Not trying to hijack but this last comment has provoked a question.
> 
> If you have multiple CentOS machines that you regularly log onto and
> use, and these share a common /home/username (via NFS or other SAN
> mechanism) how do the various . files manage to work - aren't there
> potential conflicts?
> I have two CentOS 5.5 workstations with dual monitors (different sizes
> though) and another machine with only a single display - wouldn't this
> cause issues? Unfortunately I do not have enough experience to know

The X server does not use . files in /home for display setup, it
uses /etc/X11/xorg.conf, which will be specific to the local hardware
(video card, number of monitors, etc.).

It is *presumed* that if you are in a shop with multiple
desktops/workstations using NFS / automounted /home, that the base O/S
on every machine is more or less the same version -- eg the admins do
'yum update' on all of the machines and thus keeping them all the same.

> what all these various . files contain - if they're only personal
> preferences and totally unrelated to the hardware then well and good -
> can someone confirm before I migrate my /home onto my main server and
> NFS mount it. TIA

So long as:

If all of the machines are kept more or less in sync WRT system
software versions (which is good admin practice anyway), there should
not be any problems.  Some of your . files may have to test the
environment (eg X11/Gnome related ones should be checking this and/or
using relative placement geometries).

> 
>   cite="mid:40c4699fc9f09a3b67e6c69636e41b14.squir...@host290.hostmonster.com"
>  type="cite">
> mark
> 
> ___
> CentOS mailing list
>  href="mailto:CentOS@centos.org";>CentOS@centos.org
>  href="http://lists.centos.org/mailman/listinfo/centos";>http://lists.centos.org/mailman/listinfo/centos
>   
> 
> 
> 
> 
> 
> begin:vcard
> fn:Rob Kampen
> n:Kampen;Rob
> org:Team Torman Realty
> adr:;;13019 Water Point Blvd;Windermere;FL;34786;USA
> email;internet:r...@kampensonline.net
> tel;cell:407-341-3815
> version:2.1
> end:vcard
> 
> 
> MIME-Version: 1.0
> 
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
> 
>   
>   

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Download the Model Railroad System
http://www.deepsoft.com/  -- Binaries for Linux and MS-Windows
hel...@deepsoft.com   -- http://www.deepsoft.com/ModelRailroadSystem/

 
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrade

[Robert Heller]

At Fri, 18 Jun 2010 14:59:45 -0400 CentOS mailing list  
wrote:

> 
> On Fri, Jun 18, 2010 at 02:29:32PM -0400, m.r...@5-cent.us wrote:
> 
> > And as others have said, /home, and maybe /opt, should *always* be other
> > drives, or at least other partitions
> 
> Kind of makes you wonder why RH's default install is to shove everything but
> boot into one partition these days, doesn't it? In trying to make everything
> immune from the most clueless users - who might (horrors) make a partition
> too small - RH defaults to something other than time-honored old-school best
> practices. Yeah, I never accept the defaults. But I'm not the only guy who
> ever installs RH or CentOS in my shop, and getting everyone else up to speed
> on this sort of thing only annoys 'em. They tend to take it on faith that
> the defaults are sane. They should at least come with a warning label: "This
> is our default, but if you know what you're doing, you really should
> override."

For certain flavors of servers, it might make sense to go for the 'one
big partition' method.  This might also make sense for some *desktop*
installs as well (think: desktops with NFS mounted /home/*).

But yes, the default is pretty dumb.  They do give you the option of
doing things otherwise, unlike *some* O/Ss which don't even give you
that option/choice.

> 
> Regards,
> Whit
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
> 
>   

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Download the Model Railroad System
http://www.deepsoft.com/  -- Binaries for Linux and MS-Windows
hel...@deepsoft.com   -- http://www.deepsoft.com/ModelRailroadSystem/


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] the Postfix packages are way too old

[Karanbir Singh]

On 18/06/2010 22:28, Florin Andrei wrote:
> Fun fact: Postfix-2.3.3 has been released in August 2006. Think about that.

While you are doing that - also think about this : Red Hat have a
policy, and they stick with it. Its something that works well for them,
the ISVs around the base and its something that works for us. We have a
policy too, but our policy is split into 2 segments.

1) Stick as close to upstream as possible for the main distro.

2) Its about the users and use cases. Which is unlike Red Hat's cause -
where its about a supportable base, with some level of assurance passing
through to the users about what level of support they can get when they
call a phone number. You dont get that with CentOS - but what you do get
is something like this :

- Step up and offer to maintain ( which would mean taking responsibility
for ) a newer postfix package in CentOSPlus for CentOS-4 and 5 ( Not
sure if 3 is worth doing now ). And there will be @centos.org people who
would gladly help you along the process and facilitate it.

- KB

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] the Postfix packages are way too old

[Karanbir Singh]

On 18/06/2010 23:19, John R Pierce wrote:
> isn't EL6 coming out soon ?   beta 1 released in April,  

afait ETA on el6 is august'ish this year. but C4 and C5 are still
maintained and in mass production *now*. If there is a clearcut problem
definition as this postfix issue is, then creating ( facilitating ? ) a
solution should be worth considering as well. Should it not ?

- KB
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[Karanbir Singh]

On 18/06/2010 01:09, Whit Blauvelt wrote:
> I should care what you believe? Stay ignorant, if you like. If not, take a
> CentOS system, add the EPEL repository for ganglia, try "yum install
> ganglia", and prepare to see all sorts of package conflicts. Plus it's not
> the current ganglia anyway. Better to build from tar.

A wise man once said that till such time as a bugreport is filed or
evidence to effect is shown, an issue is just a fragment of imagination
or a user induced issue they are too embarrassed to admit to. Given that
you made a wide sweeping statement that there were no usable rpms for
ganglia - I still think you don't think you what you are talking about.
I know of, and have used in the past, atleast 2 different set of rpms
that worked just fine. On the same platform as you mention, one of those
rpm sets having roots in what you hosted at EPEL / Fedora now.

To reconfirm the situation, I've just done a fresh C5 install, rolled in
epel and installed ganglia with no issues at all. If you want, I can
post a copy of the vm image used to run this test, the ks.cfg used, and
the puppet manifest that did the deployment.

> What the heck do you mean, "used ganglia in anger"? That's just incoherent.

Its an often used term in the admin / infrastructure circles to indicate
if a person has used a technology or app in conditions that would have
stressed it or used a near complete feature set.

- KB
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ganglia

[Karanbir Singh]

On 19/06/2010 02:02, Karanbir Singh wrote:
> ganglia - I still think you don't think you what you are talking about.

s/.*/ganglia - I still think you are confused about the issue./

I blame too much mongodb in one day for crazy language skilz :! ( or in
my case, lack of )

- KB
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Yum problem on Centos 5.3 (64-bit)

[Karanbir Singh]

On 18/06/2010 12:04, John Kelly wrote:
> I'm having a yum problem updating a system on Centos 5.3, 64-bit ... 
> i.e. 'yum update' returns "No Packages Marked for Update". Problem 
> appears to be related to connecting to the mirrors where the 
> repositories are located but I could be wrong in that. What's confusing 
> me is that I have another system (Centos 5.5, 32-bit) that's working fine.

Try hitting yum with a -d7; its hard to tell from the very little pasted
data as to what the issue might be. At the very least, you dont have a
valid CentOS-Base.repo in your /etc/yum.repos.d/ directory and/or your
/etc/yum.conf has been changed. To check for both of those: rpm -V
centos-release ; should tell you.

- KB
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Kernel independent OCFS2 packages for RHEL, Scientific Linux and CentOS

[Karanbir Singh]

Hi Dag,

On 18/06/2010 09:12, Dag Wieers wrote:
> I would like to announce a set of OCFS2 kABI-tracking kernel module 
> packages for RHEL5, Scientific Linux 5 and CentOS-5 and kernels.

Can you please stop spamming this list ? A one time announcement here
was plenty. Perhaps setup an announcement list for elrepo ?

- KB
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] cameras and CentOS

[Karanbir Singh]

On 17/06/2010 17:58, Dan Carl wrote:
> A capture card and zoneminder would be a more professional grade solution.

While looking for something similar, but a bit lighter weight I came
across http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome recently. Not
nearly as feature rich as ZoneMinder, but does most of the basic stuff
that I needed - including motion detection, upload to remote, run a
live-feed for a browser. Handle multiple cameras from the same machine.

- KB
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Kernel independent OCFS2 packages for RHEL, Scientific Linux and CentOS

[Dag Wieers]

On Sat, 19 Jun 2010, Karanbir Singh wrote:

> On 18/06/2010 09:12, Dag Wieers wrote:
>> I would like to announce a set of OCFS2 kABI-tracking kernel module
>> packages for RHEL5, Scientific Linux 5 and CentOS-5 and kernels.
>
> Can you please stop spamming this list ? A one time announcement here
> was plenty. Perhaps setup an announcement list for elrepo ?

Well, this is hardly spam. We are actively seeking feedback on both the 
DRBD and OCFS2 packages from users and since it is related to CentOS it 
makes sense to ask the CentOS list too. It is a coincidence that we are 
doing that for 2 packages in 3 days.

We are not sending every announcement to the CentOS list, that should be 
apparent from looking at the ELRepo lists (where actual announcements 
are being posted in more detail).

-- 
--   dag wieers,  d...@wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Kernel independent OCFS2 packages for RHEL, Scientific Linux and CentOS

[John R Pierce]

Karanbir Singh wrote:
> Hi Dag,
>
> On 18/06/2010 09:12, Dag Wieers wrote:
>   
>> I would like to announce a set of OCFS2 kABI-tracking kernel module 
>> packages for RHEL5, Scientific Linux 5 and CentOS-5 and kernels.
>> 
>
> Can you please stop spamming this list ? A one time announcement here
> was plenty. Perhaps setup an announcement list for elrepo ?
>   

I don't see this as spamming at all.   He's announcing the availability 
of various major packages specific to the EL community,   The 
announcement a few days ago was for DRBD.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Kernel independent OCFS2 packages for RHEL, Scientific Linux and CentOS

[John R. Dennison]

On Sat, Jun 19, 2010 at 02:26:16AM +0100, Karanbir Singh wrote:
> 
> Can you please stop spamming this list ? A one time announcement here
> was plenty. Perhaps setup an announcement list for elrepo ?

Unless I am missing posts this was a a one-time announcement;
Dag posted a very similar one recently about DRBD.  Personally,
I'd like to continue to see these announcements here.




John

-- 
I want a government small enough to fit inside the Constitution.

-- DownsizeDC.org co-founder Harry Browne (1933-2006)


pgp2xX20aydR2.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Kernel independent OCFS2 packages for RHEL, Scientific Linux and CentOS

[Karanbir Singh]

On 19/06/2010 02:37, John R Pierce wrote:

> I don't see this as spamming at all.   He's announcing the availability 
> of various major packages specific to the EL community,   The 
> announcement a few days ago was for DRBD.


Do you really want to see all repos announce every package they build on
the CentOS lists ?

I dont. And thats not what this list is meant for either.

An occasional announcement is fine - many people have done that, but
sending every package announcement down here isnt.

- KB
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Kernel independent OCFS2 packages for RHEL, Scientific Linux and CentOS

[Karanbir Singh]

On 19/06/2010 02:49, John R. Dennison wrote:
>   Unless I am missing posts this was a a one-time announcement;
>   Dag posted a very similar one recently about DRBD.  Personally,
>   I'd like to continue to see these announcements here.

I am sure elrepo are able to put up an announcement list, and you are
welcome to join that list. This list isnt elrepo-announce.

We don't even announce CentOS packages here.

- KB
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Kernel independent OCFS2 packages for RHEL, Scientific Linux and CentOS

[Karanbir Singh]

On 19/06/2010 02:32, Dag Wieers wrote:
> We are not sending every announcement to the CentOS list, that should be
> apparent from looking at the ELRepo lists (where actual announcements
> are being posted in more detail).

But you are still making repeated announcements about packages here - I
dont want to see every repo or development unit out there posting emails
here for feedback about every component they built. As I said already,
many projects have made a one time announcement, which is fine as long
as we don't get too many projects jumping in. If that becomes a proble,
we would need to reconsider that as well.

Anyway, keep the elrepo posts away from this list, just as every other
project is requested to not spam this list with repeated posts.

- KB

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Disabling services in CentOS 5.5

[Ryan Wagoner]

On Wed, Jun 16, 2010 at 5:06 PM, Ski Dawg  wrote:
> Hello all,
>
> I have been doing some searching for information about disabling
> services within a CentOS 5.5 install. I have found a few different
> opinions, and wanted to ask for some feedback.
>
> First off, the system is running a LAMP stack to serve a web
> application. It will only be doing email to send occasional messages
> out (sent via the application only). It will not be receiving email
> for any users. It is an CentOS 5.5 (fully updated) install running
> under VMware (esx, I believe). We are not sharing directories via nfs
> or samba (either from or to this virtual machine).
>
> >From my research, the services that I am thinking of turning off are:
> nfs (already off)
> nfslock
> portmap
> rpccgssd
> rpcidmapd
> rpcsvcgssd
> apcid
> apmd
> mdmpd
> mdmonitor
>
> Is there any reason that I need to leave any of these services
> running? Are there others that I should disable as well?
>
> Any feedback about this would be greatly appreciated.
> --
> Doug
>
> Registered Linux User #285548 (http://counter.li.org)
> 
> Never trust a computer you can't throw out a window.
>   -- Steve Wozniak
> ___

For my VMware ESXi guests I always turn off the following

bluetooth
hidd
pcscd
smartd

Ryan
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Kernel independent OCFS2 packages for RHEL, Scientific Linux and CentOS

[Whit Blauvelt]

On Sat, Jun 19, 2010 at 03:20:13AM +0100, Karanbir Singh wrote:

> But you are still making repeated announcements about packages here - I
> dont want to see every repo or development unit out there posting emails
> here for feedback about every component they built. 

Please keep things in perspective, Mr. Singh. This was no announcement about
a single component. It was about a large program for building kernel modules
- something that can be useful to many here. Might one dare to say that
Dag's many contributions to the community give him status as high as your
own? It would be better for all of us if respect were given where it has
been earned, and if guests of Dag's stature were honored, especially when
the show up bringing large gifts.

Regards,
Whit
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos