Re: [CentOS] Samba and " (and maybe other characters) in paths/files

[RedShift]

  On 06/25/10 22:48, Tom H wrote:
> On Fri, Jun 25, 2010 at 2:45 PM, Miguel Medalha  wrote:
>>> I have samba installed on my server, with a fileshare. When connecting to 
>>> samba, using windows, filesnames with " (double quotes) in them become 
>>> gibberish on the windows client.
>> Since Windows doesn't allow double quotes in filenames, Samba doesn't
>> either.
> Samba can serve files with " to Linux clients. It's a Windows
> limitation not a Samba one.

Thanks. Well that's a bit sad really...


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

Re: [CentOS] Upgrading MySQLdb

[Tsuyoshi Nagata]

Hi,
(2010年06月27日 03:15), Susan Day wrote:
> /usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.py
No-way to upgrade to latest python(2.6), MySQL(5.1), sqlalchemy(0.6).
in public centos site.Upstream policy keep running with older version until 
2014.

Your answer is just install MySQL5.1 from source code.(make install)
next time requies B, B requires C,...

I found Ubuntu 10.10 support python-sqlalchemy >0.6.
 https://launchpad.net/ubuntu/maverick/i386/python-sqlalchemy/0.6.1-1
 http://cdimage.ubuntu.com/daily-live/current/
Its easier to build environment than centos.

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

Re: [CentOS] wine 1.2 on centos

[Janez Kosmrlj]

On Mon, Jun 21, 2010 at 2:44 PM, Janez Kosmrlj
wrote:

> Hi,
>
> Has anyone tried the latest wine 1.2 RC on CentOS 5.5.
>
> We have some applications that don't work with the latest stable release.
> They require at least 1.1.34, but i would like to try 1.2.
>
> If someone has tried 1.2 on centos. Do you have build packages somewhere
> where i can get them?
>
> Regards,
>
> Janez
>
anyone???
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] centos 5.5 on optiplex 745

[Janez Kosmrlj]

Hi,
we have some old dell optiplex 745 machines which have the Intel 965q
chipset. The problem is, that they freeze as soon as the system tries to
start the X system. It happens even before any log is written. This happens
almost every time (for some reason it sometimes work, but 99% it fails).
When i change the graphic driver in xorg.conf from intel to vesa it mostly
works, but still i sometimes get a flickering screen, but this can mostly be
resolved using ctrl+alt+backspace (sometimes you have to try this twice). We
use the 1024x768 and 24 bit colors, so this shouldn't be the problem.

Does anyone know a fix for this problem?

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

Re: [CentOS] Upgrading MySQLdb

[Jim Perrin]

2010/6/28 Tsuyoshi Nagata :
> Hi,

> Your answer is just install MySQL5.1 from source code.(make install)
> next time requies B, B requires C,...


That's a horrible idea. At least use the package management system so
that dependencies can be tracked properly. Installing from source
builds directly is bad for a number of reasons.

> I found Ubuntu 10.10 support python-sqlalchemy >0.6.
>  https://launchpad.net/ubuntu/maverick/i386/python-sqlalchemy/0.6.1-1
>  http://cdimage.ubuntu.com/daily-live/current/
> Its easier to build environment than centos.



-- 
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrading MySQLdb

[Jim Perrin]

On Sat, Jun 26, 2010 at 2:15 PM, Susan Day  wrote:
> Hi;
> I've got MySQLdb installed (bridge to Python) and I can't figure out how to
> upgrade it. I did a find and got these paths:
>
> /usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.py
> /usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.pyc


Where did you get python 2.6 from? CentOS has 2.4.3 by default, and
most repos that have newer python packages drop them in /opt or
similar to avoid clobbering the default setup (and yum).


-- 
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Using CentOS on commercial product.

[Jerry McAllister]

On Mon, Jun 28, 2010 at 02:15:46PM +0900, Shinobu Takasugi wrote:

> Hello,
> 
> Thank you Jerry.
> 
> I think FreeBSD is good OS too.
> But we prefer CentOS for compatibility with Red Hat.
> 

I use both.I like FreeBSD somewhat better, but because of the
closeness to RHEL, some things are more convenient in CentOS.
But, for ease of licensing, FreeBSD wins.

jerry


> 
> When we decide to use CentOS, we will have a talk with CentOS project team
> about donation.
> 
> 
> Regards,
> Shinobu Takasugi
> 
> --
> On Fri, Jun 25, 2010 at 10:14:35AM +0900, Shinobu Takasugi wrote:
> 
>  > Hello,
>  >
>  > I've sent this mail when I didn't subscribe this mailing list.
>  > Now I subscribe and I sent again.
>  > I'm sorry to bother you.
>  >
>  >
>  > Our company make and sell some measurement system controlled by PC.
>  > We use Red Hat Enterprise Linux on the PC currently.
>  > We are thinking CentOS is another option for us.
>  > There is no technical issue but we don't have enough information about 
> license.
>  >
>  > We will do the following,
>  >
>  > 1) Install CentOS and our applications on the PC.
>  > 2) Sell the PC to our customer.
>  > 3) Distribute DVD made from CentOS iso image file to our customer.
>  >
>  > Question 1
>  > Is there no problem from the view point of CentOS license?
> 
> I don't think there is a problem using CentOS that way.
> 
> Another option might be FreeBSD.  (See http://www.freebsd.org/)
> There is definitely no problem with their license and it is a
> very good server OS.
> 
>  >
>  > Question 2
>  > Should we donate to CentOS community?
> 
> Of course, donations are always appropriate, especially if you are
> making money from the product.   But, it is not a legal requirement.
> Same is true of FreeBSD.
> 
>  >
>  >  In FAQ http://www.centos.org/modules/smartfaq/faq.php?faqid=49,
>  >  there is a description concerning donation when CentOS is used for 
> business.
>  >
> -
>  >If CentOS is the basis of your business, you should also consider making
>  >monthly donations to the CentOS Project, or even providing a dedicated
>  >server for our use.
>  >
> -
>  >
>  >
>  > Best Regards,
>  > Shinobu Takasugi
>  > --
>  >
>  > ___
>  > CentOS mailing list
>  > CentOS at centos.org
>  > http://lists.centos.org/mailman/listinfo/centos
> 
> 
> 
> ___
> 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] Virtualization as cheap redundancy option?

[Warren Young]

On 6/25/2010 8:33 AM, Brian Mathis wrote:
> - VMware Server seems like it's EOL, even though vmware hasn't
> specifically said so yet

Given that there are known serious bugs in 2.0.2[*] and that release is 
now 8 months old, that seems plausible to me.  But another plausible 
explanation is that they've decided to throw all their effort at a 3.0 
release.

Do you have any hard evidence that would help me decide between these 
two possibilities?

[*] glibc change with EL 5.4+ crashes server, creeping CPU time bug 
mentioned elsewhere in this thread, web UI buggier than Brazil in the 
rainy season...
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrading MySQLdb

[Whit Blauvelt]

On Mon, Jun 28, 2010 at 08:54:49AM -0400, Jim Perrin wrote:
> 2010/6/28 Tsuyoshi Nagata :

> > Your answer is just install MySQL5.1 from source code.(make install)

> That's a horrible idea. At least use the package management system so
> that dependencies can be tracked properly. Installing from source
> builds directly is bad for a number of reasons.

I get the theory behind why you say it's a "horrible idea." In practice, not
so much. In many years of building key programs from sourch on top of a
half-dozen different distros, for use on production servers, I have never
had a problem that could be attributed to not going through the distros'
package management systems. 

Now, I'm careful that if one program's libraries are going to get used by
something else, that I build that something else by hand too - I'm not
unmindful of dependencies, and if I were obviously stuff could fail.

But seriously, aside from the nice theory about how each package management
system cures all dependency problems (which isn't 100% true), how many
people have actually found themselves in trouble from, say, building their
own LAMP stack on whatever distro, and skipping the package management
system bottleneck entirely? Maybe I've just had rare good luck with it, but
for me it's worked without problems, ever. That said, it's become less
necesary in recent years, as the distro packages have gotten better. Yet I
don't run a single system without a few programs built from source. Despite
the theory, it has _never_ been a problem.

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

Re: [CentOS] Virtualization as cheap redundancy option?

[Whit Blauvelt]

On Mon, Jun 28, 2010 at 07:25:59AM -0600, Warren Young wrote:
> On 6/25/2010 8:33 AM, Brian Mathis wrote:
> > - VMware Server seems like it's EOL, even though vmware hasn't
> > specifically said so yet
> 
> Given that there are known serious bugs in 2.0.2[*] and that release is 
> now 8 months old, that seems plausible to me.  But another plausible 
> explanation is that they've decided to throw all their effort at a 3.0 
> release.

If you look on their site, they clearly specify that they do not offer a
paid support option for VMware Server, that it's community supported only.
Does that seem like an attitude towards a product they plan to update?

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

Re: [CentOS] Virtualization as cheap redundancy option?

[Warren Young]

On 6/28/2010 7:34 AM, Whit Blauvelt wrote:
>
> If you look on their site, they clearly specify that they do not offer a
> paid support option for VMware Server, that it's community supported only.
> Does that seem like an attitude towards a product they plan to update?

It fits completely with a low-end product they're giving away as a 
come-on for their more expensive supported products.  If the come-on 
doesn't function, it's not going to win them *any* converts from the 
free-as-in-free VM systems.  That seems counterproductive to me, so no, 
I don't believe that explains why we haven't seen a bug fix release in 8 
months.

If they wish to withdraw all support for it, I'd expect it to just 
disappear from their site.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Virtualization as cheap redundancy option?

[Brian Mathis]

On Mon, Jun 28, 2010 at 9:25 AM, Warren Young  wrote:
> On 6/25/2010 8:33 AM, Brian Mathis wrote:
>> - VMware Server seems like it's EOL, even though vmware hasn't
>> specifically said so yet
>
> Given that there are known serious bugs in 2.0.2[*] and that release is
> now 8 months old, that seems plausible to me.  But another plausible
> explanation is that they've decided to throw all their effort at a 3.0
> release.
>
> Do you have any hard evidence that would help me decide between these
> two possibilities?
>
> [*] glibc change with EL 5.4+ crashes server, creeping CPU time bug
> mentioned elsewhere in this thread, web UI buggier than Brazil in the
> rainy season...


Here is the support lifecycle page:

http://www.vmware.com/support/policies/lifecycle/general/index.html#policy_server
See the footnote under the "VMware Server" section.

Maybe there's a 3.0 in the works, but the general feeling is that they
have abandoned the product.  There have been no updates allowing the
console to work in Firefox 3.6, no fixes to the hostd crash (glibc
problem), nor any fixes to the creeping CPU problem.  These are all
major issues that would normally be addressed in any product a company
would expect to keep around.

All of these things together do not leave one with a good feeling
about the product.  Additionally, the way they are handling this has
made me feel less confident in VMware as a company, and instead of
looking at their paid products I have started looking at the
alternatives.  If they just came right out and said they were not
supporting it any longer, that would be preferable to what they are
doing now.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrading MySQLdb

[Jim Perrin]

On Mon, Jun 28, 2010 at 9:31 AM, Whit Blauvelt  wrote:

> But seriously, aside from the nice theory about how each package management
> system cures all dependency problems (which isn't 100% true), how many
> people have actually found themselves in trouble from, say, building their
> own LAMP stack on whatever distro, and skipping the package management
> system bottleneck entirely? Maybe I've just had rare good luck with it, but
> for me it's worked without problems, ever. That said, it's become less
> necesary in recent years, as the distro packages have gotten better. Yet I
> don't run a single system without a few programs built from source. Despite
> the theory, it has _never_ been a problem.

It actually counts for probably 20-30% of all the support necessary on
the irc channels with people trying to update php/mysql or similar
from source. Additionally, if you maintain multiple systems, it's far
easier to build it once within package management, and push out the
updates rather than building on each individual machine. Additionally,
when it comes to software audits, it's nice to be able to say "that
file came from this package, and has (not) been modified since install
using this verification method". Additionally, we get a large number
of questions about removing packages, or getting them back to a
default state. There are loads of packages that don't include 'make
uninstall' functionality, so your average user may be screwed if they
don't have a complete grasp of building

Basically it comes down to this. You're free to manage your systems as
you see fit. Source builds may well work just fine for you because you
seem to be aware of the intricacies involved. However recommending
that someone else do this isn't always the safe/smart play. If they
don't have the same grasp you do, and they blow up their system
because they didn't understand it... YOU, and to a lesser degree the
mailing list/distro are going to get the blame because you told them
it was the best way to go.

It may be ivory tower thinking, but to me it doesn't matter if it's
debian, ubuntu, centos, fedora, or whatever else. You use the tools
and package managers specific to your distro. to help keep things sane
for others.


-- 
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Can't install Centos with DVD on KVM.

[cliff here]

Subject line explains most of it

I'm trying to install Centos from a dvd iso, that has been verified on KVM
(Fedora 13) box.

Virtual machine boots, and will launch anaconda and will test the media, but
on the next step after that it says it can't find CD media.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrading MySQLdb

[Whit Blauvelt]

On Mon, Jun 28, 2010 at 08:58:45AM -0400, Jim Perrin wrote:
> On Sat, Jun 26, 2010 at 2:15 PM, Susan Day  wrote:
> > Hi;
> > I've got MySQLdb installed (bridge to Python) and I can't figure out how to
> > upgrade it. I did a find and got these paths:
> >
> > /usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.py
> > /usr/lib/python2.6/site-packages/SQLAlchemy-0.6beta2-py2.6.egg/sqlalchemy/dialects/mysql/mysqldb.pyc
> 
> 
> Where did you get python 2.6 from? CentOS has 2.4.3 by default, and
> most repos that have newer python packages drop them in /opt or
> similar to avoid clobbering the default setup (and yum).

And if you install Python 2.6.x from source, it by default goes into
/usr/local/, not /usr/. 

(Wouldn't it be nice if CentOS had 2.6.5 instead 2.4.3? Python improved
dramatically between those two. My systems all get Python 2.6.5 alongside
2.4.3 because (a) 2.6.5 has a lot of useful features I'm not going to refuse
to use just for CentOS purity, and (b) it's easier to write Python
3.x-compatible code in 2.6.5. Now, if I were going through the package
management system to build 2.6.5 wouldn't that risk _confusing_ the CentOS
stuff with dependencies on 2.4.3 where simply installing to /usr/local/
appears to nicely avoid that?)

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

Re: [CentOS] Virtualization as cheap redundancy option?

[guillaume]

Why would one use vmware Server 2.x when ESXi is available free of  
charge, stable, small footprint, ... ?
We have about 60 vmware machines here, about 20 of them already  
converted to ESXi and running fine.
I would never think about going back to Server 2.x or even GSX,  
especially when using veeam as a central management console.

http://www.vmware.com/products/esxi/
http://www.veeam.com/esxi-monitoring-free.html




Am 28.06.2010 um 15:45 schrieb Brian Mathis:

> On Mon, Jun 28, 2010 at 9:25 AM, Warren Young   
> wrote:
>> On 6/25/2010 8:33 AM, Brian Mathis wrote:
>>> - VMware Server seems like it's EOL, even though vmware hasn't
>>> specifically said so yet
>>
>> Given that there are known serious bugs in 2.0.2[*] and that  
>> release is
>> now 8 months old, that seems plausible to me.  But another plausible
>> explanation is that they've decided to throw all their effort at a  
>> 3.0
>> release.
>>
>> Do you have any hard evidence that would help me decide between these
>> two possibilities?
>>
>> [*] glibc change with EL 5.4+ crashes server, creeping CPU time bug
>> mentioned elsewhere in this thread, web UI buggier than Brazil in the
>> rainy season...
>
>
> Here is the support lifecycle page:
>
> http://www.vmware.com/support/policies/lifecycle/general/index.html#policy_server
> See the footnote under the "VMware Server" section.
>
> Maybe there's a 3.0 in the works, but the general feeling is that they
> have abandoned the product.  There have been no updates allowing the
> console to work in Firefox 3.6, no fixes to the hostd crash (glibc
> problem), nor any fixes to the creeping CPU problem.  These are all
> major issues that would normally be addressed in any product a company
> would expect to keep around.
>
> All of these things together do not leave one with a good feeling
> about the product.  Additionally, the way they are handling this has
> made me feel less confident in VMware as a company, and instead of
> looking at their paid products I have started looking at the
> alternatives.  If they just came right out and said they were not
> supporting it any longer, that would be preferable to what they are
> doing now.
> ___
> 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] Upgrading MySQLdb

[Jim Perrin]

On Mon, Jun 28, 2010 at 9:54 AM, Whit Blauvelt  wrote:

> (Wouldn't it be nice if CentOS had 2.6.5 instead 2.4.3? Python improved
> dramatically between those two. My systems all get Python 2.6.5 alongside
> 2.4.3 because (a) 2.6.5 has a lot of useful features I'm not going to refuse
> to use just for CentOS purity, and (b) it's easier to write Python
> 3.x-compatible code in 2.6.5. Now, if I were going through the package
> management system to build 2.6.5 wouldn't that risk _confusing_ the CentOS
> stuff with dependencies on 2.4.3 where simply installing to /usr/local/
> appears to nicely avoid that?)

On the surface, yes. However /usr/local/bin is in the $PATH first,
ahead of /usr/bin by default. so anything that doesn't call
/usr/bin/python directly causes issues. This is also a common support
theme on irc. Mostly because yes, it would be nice for a newer python,
but that will be coming in 6.x


-- 
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Virtualization as cheap redundancy option?

[Les Mikesell]

On 6/28/2010 8:25 AM, Warren Young wrote:
> On 6/25/2010 8:33 AM, Brian Mathis wrote:
>> - VMware Server seems like it's EOL, even though vmware hasn't
>> specifically said so yet
>
> Given that there are known serious bugs in 2.0.2[*] and that release is
> now 8 months old, that seems plausible to me.  But another plausible
> explanation is that they've decided to throw all their effort at a 3.0
> release.
>
> Do you have any hard evidence that would help me decide between these
> two possibilities?
>
> [*] glibc change with EL 5.4+ crashes server, creeping CPU time bug
> mentioned elsewhere in this thread, web UI buggier than Brazil in the
> rainy season...

I've never liked the web UI, so sticking with a 1.x server version seems 
like the obvious choice if it is impossible to switch to ESXi and make 
your current OS one of the guests.  Personally, thing that seems odd to 
me is that RHEL broke things in an update which is very strange 
considering the nature of the product.  I'm not so surprised that VMware 
hasn't gone out of their way to do a workaround just for RHEL/CentOS. 
The clock issue probably can't be fixed completely when running under 
some other OS.

Anyway, 1.x versions still work and don't have the glibc problem - or 
you might even use vmware player if you don't mind tying a console to 
the vm instance.  And ESXi is much better for anything resembling 
production or even a backup for production use.

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

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

Re: [CentOS] Upgrading MySQLdb

[Whit Blauvelt]

On Mon, Jun 28, 2010 at 09:49:21AM -0400, Jim Perrin wrote:

> It actually counts for probably 20-30% of all the support necessary on
> the irc channels with people trying to update php/mysql or similar
> from source. 

A large part of that problem is that people are asking for support in the
wrong place, right? 

> However recommending that someone else do this isn't always the safe/smart
> play. If they don't have the same grasp you do, and they blow up their
> system because they didn't understand it... YOU, and to a lesser degree
> the mailing list/distro are going to get the blame because you told them
> it was the best way to go.

I get it, it's a "Do as I say, not necessarily as I do" situation because
those committed to providing support through the mailing list (which CentOS
is exemplary on) don't want to have to support stuff that's outside the
scope of CentOS. That scope boundary gets fuzzy if there are too many
references to going beyond the RPM system in list comments. Perhaps each
such reference needs a footnote: "You might do this, but go somewhere else
for support of it."

> It may be ivory tower thinking, but to me it doesn't matter if it's
> debian, ubuntu, centos, fedora, or whatever else. You use the tools
> and package managers specific to your distro. to help keep things sane
> for others.

Sanity here is relative. If you go to the main support channels for stuff
like Apache or PHP or Python or Postfix or whatever, and you're having
trouble because of some bug that they fixed literally years ago, but which
your distro of choice doesn't yet provide packaged, you'll find no patience
for the "I'm not going to compile your current version because then my
distro would be impure" excuse for not upgrading to fix the problem.

So from their POV it's insane that you're staying with what they see as an
obsolete, unsupported version. Yet from a distro-centric POV it's insane
that you're not. I get both POV's. I think the take home is: If you need to
go beyond what your distro provides, you need to take your support questions
beyond your distro's channels too. 

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

Re: [CentOS] Virtualization as cheap redundancy option?

[Warren Young]

On 6/28/2010 7:59 AM, guillaume wrote:
> Why would one use vmware Server 2.x when ESXi is available free of
> charge, stable, small footprint, ... ?

I've thought about it, but it's not really the right thing for us.

Our VM host has some special hardware in it, driven by custom software 
which runs just fine in the host OS, but which doesn't work through 
virtualization because VMware doesn't know about this class of hardware.

This server is idle much of the time, so it made sense to give it 
secondary duty as a VM host.  To switch to ESXi, we'd have to bring up a 
separate server (wasteful) and let the current one go back to being idle 
much of the time (doubly wasteful).
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrading MySQLdb

[Les Mikesell]

On 6/28/2010 9:46 AM, Whit Blauvelt wrote:
> On Mon, Jun 28, 2010 at 09:49:21AM -0400, Jim Perrin wrote:
>
>> It actually counts for probably 20-30% of all the support necessary on
>> the irc channels with people trying to update php/mysql or similar
>> from source.
>
> A large part of that problem is that people are asking for support in the
> wrong place, right?

No, the fact that your ability to 'yum update' and have the right thing 
happen is broken is a big problem regardless of who/where you ask for 
help.  Even if you break it yourself, it is bad that it is broken.

>> However recommending that someone else do this isn't always the safe/smart
>> play. If they don't have the same grasp you do, and they blow up their
>> system because they didn't understand it... YOU, and to a lesser degree
>> the mailing list/distro are going to get the blame because you told them
>> it was the best way to go.
>
> I get it, it's a "Do as I say, not necessarily as I do" situation because
> those committed to providing support through the mailing list (which CentOS
> is exemplary on) don't want to have to support stuff that's outside the
> scope of CentOS. That scope boundary gets fuzzy if there are too many
> references to going beyond the RPM system in list comments. Perhaps each
> such reference needs a footnote: "You might do this, but go somewhere else
> for support of it."

Think of rpm as a database with consistency rules needed to manage your 
system - and yum as an application that requires database consistency. 
Because that's what they are.  Now think about what happens when you 
randomly scribble over database values, ignoring the consistency rules. 
  Because that's what you are doing when you replace file contents that 
rpm thinks it is managing in its database.

>> It may be ivory tower thinking, but to me it doesn't matter if it's
>> debian, ubuntu, centos, fedora, or whatever else. You use the tools
>> and package managers specific to your distro. to help keep things sane
>> for others.
>
> Sanity here is relative.

Does anyone ever think their own choices are not sane - even when they 
aren't?

> If you go to the main support channels for stuff
> like Apache or PHP or Python or Postfix or whatever, and you're having
> trouble because of some bug that they fixed literally years ago, but which
> your distro of choice doesn't yet provide packaged, you'll find no patience
> for the "I'm not going to compile your current version because then my
> distro would be impure" excuse for not upgrading to fix the problem.
>
> So from their POV it's insane that you're staying with what they see as an
> obsolete, unsupported version. Yet from a distro-centric POV it's insane
> that you're not. I get both POV's. I think the take home is: If you need to
> go beyond what your distro provides, you need to take your support questions
> beyond your distro's channels too.

Support isn't so much the point as not breaking your system in the first 
place.  And there are three easy ways to not break it. In order of 
increasing difficulty:

1) find a yum repo with suitable RPMs already built and maintained (e.g. 
remi for mysql) and enable that repo only for the yum install and update 
commands for this particular app.

2) build from source, but be sure everything lands in /usr/local, /opt, 
or other location completely outside of any packages under rpm control. 
  Track updates yourself and be sure you know how to delete all files 
that were installed.  Do plenty of testing if you use developer source 
releases - because no one else may have.

3) build/maintain from source and package your own rpm that wins over 
the stock version and doesn't create additional conflicts.

Under some circumstances option 3 may be less work than 2 (spec file 
already available, multiple machines to maintain, etc.).

And since the RHEL6 beta is out, yet another option might be to grab a 
src rpm from ftp://ftp.redhat.com/pub/redhat/rhel/beta/6/source/SRPMS/ 
and see if it will build and install.  If it works, that might make for 
the easiest transition in a future system upgrade - and you would still 
get a 'fairly well tested' version compared to what might be the latest 
developer release.

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

Re: [CentOS] Upgrading MySQLdb

[Jim Perrin]

On Mon, Jun 28, 2010 at 10:46 AM, Whit Blauvelt  wrote:

> Sanity here is relative. If you go to the main support channels for stuff
> like Apache or PHP or Python or Postfix or whatever, and you're having
> trouble because of some bug that they fixed literally years ago, but which
> your distro of choice doesn't yet provide packaged, you'll find no patience
> for the "I'm not going to compile your current version because then my
> distro would be impure" excuse for not upgrading to fix the problem.

Not at all. I'm not saying ZOMG YOU MUST STAY WITH 5.1.6 FOR
PHP!eleventy!

I'm simply saying that for most people, the configure make make
install method of doing things can and likely will result in breakage.
Either take the extra 5 minutes to make it into an rpm or stand on the
shoulders of others who already have, like the IUS repo folks, or the
epel repo folks, or the atrpms or rpmforge folks to get what you need.
My gripe is not about keeping the distro pure (that's a whole separate
issue), but simply keeping the package management overhead simple and
in general line with the practices of the distro.

In any event, we're drifting pretty far from the initial nature of
this thread, so I'd like to move that we either start a separate one
for this sort of thing, or cease altogether. I'm mostly in favor of
the latter.

-- 
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Yum archive for PHP greater than 5.2.1 for CentOS 5.4?

[kOoLiNuS]

Joseph L. Casale wrote:

Whether I like it or not I need to get a version of PHP that is greater than 
5.2.1
 


http://blog.famillecollet.com/pages/Config-en
   


+1
with EPEL this is what I use on my systems too (but disable the repo 
after installation since they update fast)


--
Nicola Losito.:kOoLiNuS:.
http://claimid.com/koolinus
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Yum archive for PHP greater than 5.2.1 for CentOS 5.4?

[Baird, Josh]

Check the centosextra's repo.

 

Josh

 

From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On
Behalf Of kOoLiNuS
Sent: Monday, June 28, 2010 10:54 AM
To: CentOS mailing list
Subject: Re: [CentOS] Yum archive for PHP greater than 5.2.1 for CentOS
5.4?

 



Joseph L. Casale wrote: 

Whether I like it or not I need to get a version of PHP that is
greater than 5.2.1


 
http://blog.famillecollet.com/pages/Config-en
  


+1
with EPEL this is what I use on my systems too (but disable the repo
after installation since they update fast)

-- 
Nicola Losito.:kOoLiNuS:.
http://claimid.com/koolinus

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

Re: [CentOS] Virtualization as cheap redundancy option?

[Ross Walker]

On Jun 28, 2010, at 11:15 AM, Warren Young  wrote:

> On 6/28/2010 7:59 AM, guillaume wrote:
>> Why would one use vmware Server 2.x when ESXi is available free of
>> charge, stable, small footprint, ... ?
> 
> I've thought about it, but it's not really the right thing for us.
> 
> Our VM host has some special hardware in it, driven by custom software 
> which runs just fine in the host OS, but which doesn't work through 
> virtualization because VMware doesn't know about this class of hardware.
> 
> This server is idle much of the time, so it made sense to give it 
> secondary duty as a VM host.  To switch to ESXi, we'd have to bring up a 
> separate server (wasteful) and let the current one go back to being idle 
> much of the time (doubly wasteful).

Then give VirtualBox a whirl.

Fully supported, works and some say performs better then VMware Server.

-Ross

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

Re: [CentOS] Yum archive for PHP greater than 5.2.1 for CentOS 5.4?

[Baird, Josh]

I'm sorry, I meant the 'c5-testing' repo.

 

From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On
Behalf Of Baird, Josh
Sent: Monday, June 28, 2010 10:57 AM
To: CentOS mailing list
Subject: Re: [CentOS] Yum archive for PHP greater than 5.2.1 for CentOS
5.4?

 

Check the centosextra's repo.

 

Josh

 

From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On
Behalf Of kOoLiNuS
Sent: Monday, June 28, 2010 10:54 AM
To: CentOS mailing list
Subject: Re: [CentOS] Yum archive for PHP greater than 5.2.1 for CentOS
5.4?

 



Joseph L. Casale wrote: 

Whether I like it or not I need to get a version of PHP that is
greater than 5.2.1


 
http://blog.famillecollet.com/pages/Config-en
  


+1
with EPEL this is what I use on my systems too (but disable the repo
after installation since they update fast)

-- 
Nicola Losito.:kOoLiNuS:.
http://claimid.com/koolinus

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

Re: [CentOS] Upgrading MySQLdb

[m . roth]

Les Mikesell wrote:
> On 6/28/2010 9:46 AM, Whit Blauvelt wrote:
>> On Mon, Jun 28, 2010 at 09:49:21AM -0400, Jim Perrin wrote:
>>

> No, the fact that your ability to 'yum update' and have the right thing
> happen is broken is a big problem regardless of who/where you ask for
> help.  Even if you break it yourself, it is bad that it is broken.

As much as I would rather do something myself, at times, Les is right. If
you get a job offer somewhere else, suddenly, think of the next person who
has to maintain this.
>


> place.  And there are three easy ways to not break it. In order of
> increasing difficulty:
>
> 1) find a yum repo with suitable RPMs already built and maintained (e.g.
> remi for mysql) and enable that repo only for the yum install and update
> commands for this particular app.
>
> 2) build from source, but be sure everything lands in /usr/local, /opt,
> or other location completely outside of any packages under rpm control.
>   Track updates yourself and be sure you know how to delete all files
> that were installed.  Do plenty of testing if you use developer source
> releases - because no one else may have.

I think 2 is the way you may need to go for some things. One of our
servers here, and at a place I used to work at, needed a) a newer version
of PHP, and the other place also needed https support in php, which was
*not* in the repository. So, the source tarball got d/l from the project
site, and built in /usr/local, where, IMO, was where it should be. That
way, you can not worry about what yum's doing, because your apache
configuration will point to /usr/local, and there's be no accidents.

 mark

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

Re: [CentOS] Virtualization as cheap redundancy option?

[John R Pierce]

On 06/28/10 8:57 AM, Ross Walker wrote:
> Then give VirtualBox a whirl.
> Fully supported, works and some say performs better then VMware Server.
>


I second the emotion on VBox, its a nice piece of work.

Read the license carefully, however.   Its no longer free for use as a 
server in a business environment, only free for 'personal' use.   Larry 
needs a new boat.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Virtualization as cheap redundancy option?

[Whit Blauvelt]

On Mon, Jun 28, 2010 at 09:06:43AM -0700, John R Pierce wrote:

> I second the emotion on VBox, its a nice piece of work.
> 
> Read the license carefully, however.   Its no longer free for use as a 
> server in a business environment, only free for 'personal' use.   Larry 
> needs a new boat.

They also clarify that 'personal' use can include in a business environment,
if you're just installing on a system here and there and not doing a mass
rollout on multiple machines. But that's from their website. Haven't read
the full license to see how closely their informal synopsis matches the
lawyereese.

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

Re: [CentOS] Virtualization as cheap redundancy option?

[Les Mikesell]

On 6/28/2010 10:15 AM, Warren Young wrote:
> On 6/28/2010 7:59 AM, guillaume wrote:
>> Why would one use vmware Server 2.x when ESXi is available free of
>> charge, stable, small footprint, ... ?
>
> I've thought about it, but it's not really the right thing for us.
>
> Our VM host has some special hardware in it, driven by custom software
> which runs just fine in the host OS, but which doesn't work through
> virtualization because VMware doesn't know about this class of hardware.

What kind of hardware?  Is it something that could be replaced by a 
supported card or a usb device that a guest could access?

> This server is idle much of the time, so it made sense to give it
> secondary duty as a VM host.  To switch to ESXi, we'd have to bring up a
> separate server (wasteful) and let the current one go back to being idle
> much of the time (doubly wasteful).

That still leaves the Server 1.x version as an option.  It's been rock 
solid for me for years and the only thing that RHEL/Centos5 being 
'unsupported' hosts means is that after each kernel update you have to 
run the script that recompiles the kernel module - which is not a 
problem as long as you have the compiler and kernel header packages 
installed.

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

Re: [CentOS] Upgrading MySQLdb

[Whit Blauvelt]

On Mon, Jun 28, 2010 at 11:48:48AM -0400, m.r...@5-cent.us wrote:
> Les Mikesell wrote:

> >> On Mon, Jun 28, 2010 at 09:49:21AM -0400, Jim Perrin wrote:
> >>
> > No, the fact that your ability to 'yum update' and have the right thing
> > happen is broken is a big problem regardless of who/where you ask for
> > help.  Even if you break it yourself, it is bad that it is broken.
> 
> As much as I would rather do something myself, at times, Les is right. If
> you get a job offer somewhere else, suddenly, think of the next person who
> has to maintain this.

That's why I always thoroughly log all stuff installed by hand, along with
extra configuration steps taken with RPM-installed items, and make sure the
log's someplace where the next person can find it. In our case we maintain
wikis for this sort of thing. It would be nice if there were a standard for
where such notes should be left on the systems themselves. Not aware that
there is one, though.

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

Re: [CentOS] Virtualization as cheap redundancy option?

[John R Pierce]

On 06/28/10 9:19 AM, Whit Blauvelt wrote:
> On Mon, Jun 28, 2010 at 09:06:43AM -0700, John R Pierce wrote:
>
>
>> I second the emotion on VBox, its a nice piece of work.
>>
>> Read the license carefully, however.   Its no longer free for use as a
>> server in a business environment, only free for 'personal' use.   Larry
>> needs a new boat.
>>  
> They also clarify that 'personal' use can include in a business environment,
> if you're just installing on a system here and there and not doing a mass
> rollout on multiple machines. But that's from their website. Haven't read
> the full license to see how closely their informal synopsis matches the
> lawyereese.
>

what I read said personal use in a business environment meant the VM 
isn't a server accessed by anyone else.   I can run vbox on my office 
desktop and host a VM for my own use.  I can't, however, host a 
webserver VM that my department uses.

but IANAL.

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

Re: [CentOS] Upgrading MySQLdb

[Les Mikesell]

On 6/28/2010 11:24 AM, Whit Blauvelt wrote:

>>> No, the fact that your ability to 'yum update' and have the right thing
>>> happen is broken is a big problem regardless of who/where you ask for
>>> help.  Even if you break it yourself, it is bad that it is broken.
>>
>> As much as I would rather do something myself, at times, Les is right. If
>> you get a job offer somewhere else, suddenly, think of the next person who
>> has to maintain this.
>
> That's why I always thoroughly log all stuff installed by hand, along with
> extra configuration steps taken with RPM-installed items, and make sure the
> log's someplace where the next person can find it. In our case we maintain
> wikis for this sort of thing. It would be nice if there were a standard for
> where such notes should be left on the systems themselves. Not aware that
> there is one, though.

The standard place is for the rpm database to hold the list of files in 
each package and to the extent possible values for local config options 
to be split out as a file under /etc/sysconfig and somehow merged at 
runtime.  And the standard for documentation would be matching man pages 
included in the package.

The piece you might be missing is avoiding replacing any rpm-managed 
file with your own.   Or putting your own files in places that might 
conflict with subsequently installed rpms.

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


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

Re: [CentOS] Virtualization as cheap redundancy option?

[Ross Walker]

On Jun 28, 2010, at 12:40 PM, John R Pierce  wrote:

> On 06/28/10 9:19 AM, Whit Blauvelt wrote:
>> On Mon, Jun 28, 2010 at 09:06:43AM -0700, John R Pierce wrote:
>> 
>> 
>>> I second the emotion on VBox, its a nice piece of work.
>>> 
>>> Read the license carefully, however.   Its no longer free for use as a
>>> server in a business environment, only free for 'personal' use.   Larry
>>> needs a new boat.
>>> 
>> They also clarify that 'personal' use can include in a business environment,
>> if you're just installing on a system here and there and not doing a mass
>> rollout on multiple machines. But that's from their website. Haven't read
>> the full license to see how closely their informal synopsis matches the
>> lawyereese.
>> 
> 
> what I read said personal use in a business environment meant the VM 
> isn't a server accessed by anyone else.   I can run vbox on my office 
> desktop and host a VM for my own use.  I can't, however, host a 
> webserver VM that my department uses.
> 
> but IANAL.

If you use it in a production environment you will probably want to buy support 
where you can request bug fixes and such.

But nobody is going to audit you if your performing an "extended" evaluation of 
the product.

Most people who end up installing it for large deployments end up buying the 
support, if not to be 'legit', then for regulatory compliance reasons.

-Ross

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

Re: [CentOS] Virtualization as cheap redundancy option?

[Scott Silva]

on 6-28-2010 6:34 AM Whit Blauvelt spake the following:
> On Mon, Jun 28, 2010 at 07:25:59AM -0600, Warren Young wrote:
>> On 6/25/2010 8:33 AM, Brian Mathis wrote:
>>> - VMware Server seems like it's EOL, even though vmware hasn't
>>> specifically said so yet
>>
>> Given that there are known serious bugs in 2.0.2[*] and that release is 
>> now 8 months old, that seems plausible to me.  But another plausible 
>> explanation is that they've decided to throw all their effort at a 3.0 
>> release.
> 
> If you look on their site, they clearly specify that they do not offer a
> paid support option for VMware Server, that it's community supported only.
> Does that seem like an attitude towards a product they plan to update?
> 
> Whit
That just looks like they don't want to support something they give away...

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

[CentOS] Upgrading MySQL

[Susan Day]

Hi;
I'm trying to install django and got this error:

django.core.exceptions.ImproperlyConfigured: MySQLdb-1.2.1p2 or newer is
required; you have 1.2.1

So then I tried yum upgrade mysql and got this:

No Packages marked for Update

Please advise.
TIA,
Susan
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Virtualization as cheap redundancy option?

[Benjamin Franz]

On 06/28/2010 10:15 AM, Scott Silva wrote:
> on 6-28-2010 6:34 AM Whit Blauvelt spake the following:
>
>> If you look on their site, they clearly specify that they do not offer a
>> paid support option for VMware Server, that it's community supported only.
>> Does that seem like an attitude towards a product they plan to update?
>>
>> Whit
>>  
> That just looks like they don't want to support something they give away...
>

They give away ESXi, too, so that argument is pretty weak. The 
difference is that ESXi is directly tied to their other tracks and 
support. VM Server has always been pretty 'standalone'. Not so good if 
your business models is convincing people to buy all the pretty add ons.

They more-or-less abrogated their own lifecycle guidelines with VM 
Server by declaring that 'General' support for it only includes 
'Technical Guidance' until EOL (there-by skipping directly to their 
lowest level of support - which is pretty much 'Google it and look in 
the forums').

At this point VM Server is in the 'if it breaks you get to keep all the 
pieces' mode.

-- 
Benjamin Franz

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

Re: [CentOS] Virtualization as cheap redundancy option?

[Les Mikesell]

On 6/28/2010 12:39 PM, Benjamin Franz wrote:
>
> At this point VM Server is in the 'if it breaks you get to keep all the
> pieces' mode.

Like just about all software, although you might get the chance for a 
refund on what you paid if you can prove there is a problem with 
advertised capabilities.

Anyway, I'll repeat that my experience with VMware server 1.x has been 
years of running under both CentOS 3.x and 5.x and no breakage at all so 
far.

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




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

Re: [CentOS] Upgrading MySQLdbyg

[Whit Blauvelt]

On Mon, Jun 28, 2010 at 11:58:14AM -0500, Les Mikesell wrote:

> > That's why I always thoroughly log all stuff installed by hand, along with
> > extra configuration steps taken with RPM-installed items, and make sure the
> > log's someplace where the next person can find it. In our case we maintain
> > wikis for this sort of thing. It would be nice if there were a standard for
> > where such notes should be left on the systems themselves. Not aware that
> > there is one, though.
> 
> The standard place is for the rpm database to hold the list of files in 
> each package and to the extent possible values for local config options 
> to be split out as a file under /etc/sysconfig and somehow merged at 
> runtime.  And the standard for documentation would be matching man pages 
> included in the package.

Les, that's not my question. My question is about there being a standard
place to record what's installed _outside_ of the distro's package
management scheme. IMHO telling people it's not proper to do that is an
attempt to impose a local custom in a world where many people are more
sophisticated, and blend customs from various communities.

> The piece you might be missing is avoiding replacing any rpm-managed 
> file with your own.   Or putting your own files in places that might 
> conflict with subsequently installed rpms.

Ah, but you see I'm resulutely not "proper" and will always install some
things directly from tar where the distro (whichever distro) isn't current
enough for our needs, or has compiled a daemon with options inappropriate to
our uses. I do, though, install these in locations like
/usr/local/ outside of the areas the distro is maintaining. There is of
course a standard about distros not touching /usr/local/. Some prefer /opt,
but some distros find their own conflicting uses for that directory,
unfortunately. I also keep a log when I do these installs, so the next
sysadmin will know. The question is if there's a standard place to keep
that.

I'm certainly not coming to this list and complaining when anything I've
built by hand on top of CentOS doesn't do what I want. I get it that the
regulars here don't want to support that. Trying to convince everyone not to
build and install anything from tar, ever, may be overkill. Wearing my
sysadmin hat I appreciate the conservative approach; but I also wear a
developer hat, from which POV sticking with obsolete programs just to make
the sysadmin half of me maximally comfortable is too serious a compromise.

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

Re: [CentOS] Upgrading MySQLdbyg

[m . roth]

Whit Blauvelt wrote:
> On Mon, Jun 28, 2010 at 11:58:14AM -0500, Les Mikesell wrote:
>
>> > That's why I always thoroughly log all stuff installed by hand, along
>> > with extra configuration steps taken with RPM-installed items, and make
>> > sure the log's someplace where the next person can find it. In our
case we
>> > maintain wikis for this sort of thing. It would be nice if there were a
>> > standard for where such notes should be left on the systems
themselves. Not aware
>> > that there is one, though.
>>
>> The standard place is for the rpm database to hold the list of files in
>> each package and to the extent possible values for local config options
>> to be split out as a file under /etc/sysconfig and somehow merged at
>> runtime.  And the standard for documentation would be matching man pages
>> included in the package.
>
> Les, that's not my question. My question is about there being a standard
> place to record what's installed _outside_ of the distro's package
> management scheme. IMHO telling people it's not proper to do that is an
> attempt to impose a local custom in a world where many people are more
> sophisticated, and blend customs from various communities.

Y'know, I sorta like that idea - say, a script or program that you can
hand it info, such as if you've just built PHP the way I mentioned, and
have it be added to the rpmdb. That would also let you know if you did a
yum updgrade, and if a newer version than what you'd build had been added
to the regular distro.

 mark

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

Re: [CentOS] Upgrading MySQL

[Karanbir Singh]

On 28/06/2010 18:21, Susan Day wrote:
> Hi;
> I'm trying to install django and got this error:
> 
> django.core.exceptions.ImproperlyConfigured: MySQLdb-1.2.1p2 or newer is
> required; you have 1.2.1
> 
> So then I tried yum upgrade mysql and got this:

You should go and talk about this in the django lists, you clearly need
very basic help.

Also, that message indicates you need a newer MySQL-python package, not
mysql. Have you considered starting with a very basic tutorial on django
and python first ? Getting some of the concepts right, early on, will
help make sure you go a lot further.

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

[CentOS] Upgrading MySQLdbyg

[R P Herrold]

On Mon, 28 Jun 2010, m.r...@5-cent.us wrote:

> Y'know, I sorta like that idea - say, a script or program that you can
> hand it info, such as if you've just built PHP the way I mentioned, and
> have it be added to the rpmdb. That would also let you know if you did a
> yum updgrade, and if a newer version than what you'd build had been added
> to the regular distro.

and this random guessing and recordatation to pollute the RPM 
database "varies from ** and ** is better than" using a 
package built from a pre-defined recipe driven by a .spec 
file, just how?

packaging is not rocket science; building packages from a spec 
file and tarball and patches is profusely documented

All RPM needs is for people to read and use the tools, and all 
this is done well presently

"Those who don't understand UNIX are condemned to reinvent it, 
poorly." – Henry Spencer

RPM is a barracuda swimming through the *nix seas, ready to 
exceed the capabilities of pre-schoolers on tricycles on a 
moment's notice

Talking about random poor approaches on this mailing list 
helps no-one who might wrongly conclude hereafter that those 
approaches are good ideas

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

Re: [CentOS] Upgrading MySQLdbyg

[Les Mikesell]

On 6/28/2010 1:01 PM, Whit Blauvelt wrote:
>
>>> That's why I always thoroughly log all stuff installed by hand, along with
>>> extra configuration steps taken with RPM-installed items, and make sure the
>>> log's someplace where the next person can find it. In our case we maintain
>>> wikis for this sort of thing. It would be nice if there were a standard for
>>> where such notes should be left on the systems themselves. Not aware that
>>> there is one, though.
>>
>> The standard place is for the rpm database to hold the list of files in
>> each package and to the extent possible values for local config options
>> to be split out as a file under /etc/sysconfig and somehow merged at
>> runtime.  And the standard for documentation would be matching man pages
>> included in the package.
>
> Les, that's not my question. My question is about there being a standard
> place to record what's installed _outside_ of the distro's package
> management scheme. IMHO telling people it's not proper to do that is an
> attempt to impose a local custom in a world where many people are more
> sophisticated, and blend customs from various communities.

I don't think there is such a standard and it doesn't make much sense 
for it to be a part of the machine itself anyway.  You really need this 
stuff on a separate system where it will be available when you are 
trying to re-create the machine in question after it dies or you are 
reinstalling your backups.  Wiki's are probably a common choice - or 
documents managed in a well-backed-up revision control repository.  On 
the machine itself, if I edit things by hand I try to include comments 
if possible, and leave the original lines intact but commented out - and 
in a few cases I grab copies of these files via rsync to a central 
location and commit to a subversion repository periodically.  Then 
running 'viewvc' with that repository permits web viewing of color-coded 
diffs of any versions that have ever been committed.  This is also a 
good way to handle things like router configs that can be handled as 
text files. If you do the commit step by hand you can add comments about 
why the change was made that you will be able to read in the revision 
history.   It isn't hard to set up subversion and viewvc (although 
somewhat related to this discussion, you'd want much newer releases like 
those at rpmforge), but it would be nice if something like that was set 
up to store at least everything under /etc that didn't match the 
rpm-installed version came as part of the system - and even better if it 
could treat many similar systems as branches from the base install in 
the versioning scheme.

> I'm certainly not coming to this list and complaining when anything I've
> built by hand on top of CentOS doesn't do what I want. I get it that the
> regulars here don't want to support that. Trying to convince everyone not to
> build and install anything from tar, ever, may be overkill. Wearing my
> sysadmin hat I appreciate the conservative approach; but I also wear a
> developer hat, from which POV sticking with obsolete programs just to make
> the sysadmin half of me maximally comfortable is too serious a compromise.

Developers typically know how to build things such that multiple 
versions of the same libraries and apps can co-exist at once.  RPM, 
unfortunately, isn't that bright.  I'm not a purist about using RPM 
myself and consider it entirely reasonable to have locally built 
versions of a few things in your $HOME/user/bin or /user/local/bin 
directories as long as you understand the side effects - and that 
includes knowing the search order of $PATH and perhaps $LD_LIBRARY_PATH 
that other things on the machine might be using.

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

Re: [CentOS] Upgrading MySQLdbyg

[m . roth]

R P Herrold wrote:
> On Mon, 28 Jun 2010, m.r...@5-cent.us wrote:
>
>> Y'know, I sorta like that idea - say, a script or program that you can
>> hand it info, such as if you've just built PHP the way I mentioned, and
>> have it be added to the rpmdb. That would also let you know if you did a
>> yum updgrade, and if a newer version than what you'd build had been
>> added to the regular distro.
>
> and this random guessing and recordatation to pollute the RPM
> database "varies from ** and ** is better than" using a
> package built from a pre-defined recipe driven by a .spec
> file, just how?

Well, when it insists on building in /usr/src/redhat, and then cannot find
a std. include file (config.h, down in, say,
/lib/modules/2.6.18-194.3.1.el5/build/include/linux/config.h), as happened
to me a week or two ago I'd *MUCH* rather have one directory, with
everything in it related to whatever I was building, and have *one* place
to tell it what it needed to find (such as the above).
>
> packaging is not rocket science; building packages from a spec
> file and tarball and patches is profusely documented
>
> All RPM needs is for people to read and use the tools, and all
> this is done well presently

Right. And the folks who build packages and don't even consider the
possibility of looking at a *higher* subrelease of a library (had that a
number of times). We won't even begin to talk about python

 mark

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

Re: [CentOS] Dual nw card problem again

[Scott Silva]

on 6-27-2010 2:20 PM Jussi Hirvi spake the following:
> I have had problems like this before. Probably there is something 
> important that I don't know about routing.
> 
> Let me introduce to you "Lasso2", a CentOS 4 www server that has been 
> working perfectly well for years.
> 
> Now I added a second nw card (eth1), automatically using kudzu. I cannot 
> get this dual nw setup to work. The first nw card (eth0) stopped at once 
> working properly, when I added the second card. Hw failure is probably 
> outruled - the connection via eth0 works normally again if I remove the 
> eth1 card and its settings (on reboot with kudzu).
> 
> There are several symptoms with the dual nw card setup, and I cannot 
> really get to diagnosis.
> 
> 1) if you ping lasso2 (the problem machine) with the eth0 ip, the ping 
> requests come in ok, but the ping responses leave the machine via eth2 - 
eth2 or eth1?
> not good. I don't really know how to analyze routing and how to use ip 
> (the program) to fix it, so please tell me about it.
> 
> The "ip route show" output looks perfectly normal to me, it is similar 
> to another 2-card machine I have running (though that is Centos v5)
> 
> [r...@lasso2 ~]# ip route show
> 62.236.221.64/28 dev eth1  proto kernel  scope link  src 62.236.221.75
> 62.220.237.96/27 dev eth0  proto kernel  scope link  src 62.220.237.114
> 169.254.0.0/16 dev eth1  scope link
> default via 62.236.221.65 dev eth1
Eth1 is your default route, so everything is going to try and go out that way.


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

Re: [CentOS] Upgrading MySQLdbyg

[Les Mikesell]

On 6/28/2010 1:43 PM, R P Herrold wrote:
>
> All RPM needs is for people to read and use the tools, and all
> this is done well presently

What's the right approach with RPM to have multiple versions of an 
application installed simultaneously?

> "Those who don't understand UNIX are condemned to reinvent it,
> poorly." – Henry Spencer

Yes, but unix was developed from the beginning with the idea of having 
test and production instances installed simultaneously and different 
users having their own different local copies of libraries and 
executables.  It is RPM that doesn't understand those concepts.

And while you are at it, what's the right approach for using RPMs that 
are developed without coordinating their namespaces with all other 
potential sources of RPMs.

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

Re: [CentOS] Can't install Centos with DVD on KVM.

[cliff here]

still stumped.

On Mon, Jun 28, 2010 at 9:51 AM, cliff here  wrote:

> Subject line explains most of it
>
> I'm trying to install Centos from a dvd iso, that has been verified on KVM
> (Fedora 13) box.
>
> Virtual machine boots, and will launch anaconda and will test the media,
> but on the next step after that it says it can't find CD media.
>



-- 
-
NOTICE: This message, including all attachments, is intended for the use of
the individual or entity to which it is addressed and may contain
information that is privileged, confidential and exempt from disclosure
under applicable law. If the reader of this message is not the intended
recipient, or the employee or agent responsible for delivering this message
to its intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you
have received this communication in error, please notify the sender
immediately by replying "Received in error" and immediately delete this
message and all its attachments.
-
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Upgrading MySQLdbyg

[R P Herrold]

On Mon, 28 Jun 2010, m.r...@5-cent.us wrote:

> R P Herrold wrote:
>> and this random guessing and recordatation to pollute the RPM
>> database "varies from ** and ** is better than" using a
>> package built from a pre-defined recipe driven by a .spec
>> file, just how?

> Well, when it insists on building in /usr/src/redhat,

bzrrrttt --- no such insistance by RPM; just the opposite as 
it it is fully configurable -- also building as root is a well 
known and readily avoidable stupidity
http://www.owlriver.com/tips/non-root/

> to me a week or two ago I'd *MUCH* rather have one directory, with
> everything in it related to whatever I was building, and have *one* place
> to tell it what it needed to find (such as the above).

Nothing in RPM building practice prevents gathering local 
collections of packages that relate to one another -- I've 
published such cluster collections to satisfy dependencies for 
years and years
ftp://ftp.owlriver.com/pub/mirror/ORC/bugzilla/

> Right. And the folks who build packages and don't even consider the
> possibility of looking at a *higher* subrelease of a library (had that a
> number of times)

Namespace collisions are the responsibility of the craftsman, 
not the tool, of course; stow and alternatives work perfectly 
fine if one 'needs' to swap between such in build 
environments; packages using autotools and 'configure' 
sensible and richly also readily provide for parallel 
versioned library installs -- not RPM's job, mon

> We won't even begin to talk about python

The Python community tout weak type checking as acceptible, 
along with limited namespace disambiguation tools; they lack 
the interest to follow the convention of holding an API stable 
across a major version number, and so transfer the burden to 
their using community.  I understand why it seemed like a 
better choice than say, perl, to Red Hat, but there are some 
major faults in Python space as well

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

[CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Emmanuel Noobadmin]

Has anybody tried or knows if it is possible to create a MD RAID1
device using networked iSCSI devices like those created using
OpenFiler?

The idea I'm thinking of here is to use two OpenFiler servers with
physical drives in RAID 1, to create iSCSI virtual devices and run
CentOS guest VMs off the MD RAID 1 device. Since theoretically, this
setup would survive both a single physical drive failure as well as a
machine failure on the storage side with a much shorter failover time
than say using heartbeat.

Or is this yet another stupid idea again from me? :D
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Upgrading MySQLdbyg

[R P Herrold]

On Mon, 28 Jun 2010, Les Mikesell wrote:

> On 6/28/2010 1:43 PM, R P Herrold wrote:
>>
>> All RPM needs is for people to read and use the tools, and all
>> this is done well presently
>
> What's the right approach with RPM to have multiple versions of an
> application installed simultaneously?

stow, alternatives, and versioned namespaces already discussed 
in my last post on this thread

>> "Those who don't understand UNIX are condemned to reinvent it,
>> poorly." – Henry Spencer
>
> Yes, but unix was developed from the beginning with the idea of having
> test and production instances installed simultaneously and different
> users having their own different local copies of libraries and
> executables.  It is RPM that doesn't understand those concepts.

I started in the commercial Unix world with HP-UX; in Linux 
with binary TGZ-balls - I recall their approach and HP Depot 
files.  Each are a poor knockoff, compared to the richness of 
expression possible with RPM (or .deb)

RPM understands those concepts well, and supports working with 
the autotools; it will happily set up, build in, an run test 
in 'build chroots' populated to taste with various versions

> And while you are at it, what's the right approach for using RPMs that
> are developed without coordinating their namespaces with all other
> potential sources of RPMs.

This is a political problem, and not a technical one.  LANANA 
is (properly) will not willing to impose a solution, but 
rather to assign namespaces without collision; the FHS offers 
quidance; th LSB is the only 'rosetta stone' interchange point 
of any mass other than defacto ones build up by vendors and 
prominent independents

Answered the other way: the 'right' approach is to avoid poor 
packagers and prefer good ones.  In self defense, I package to 
meet my quality needs, pulling liberally from 'good' peers. 
I see that my archive holds 839 SRPM packages in 350 groups 
listed that all largely interop [or are obsoleted but left 
for others who may want them]

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

Re: [CentOS] Can't install Centos with DVD on KVM.

[Karanbir Singh]

On 28/06/2010 20:12, cliff here wrote:
> still stumped.
> 
> On Mon, Jun 28, 2010 at 9:51 AM, cliff here  Virtual machine boots, and will launch anaconda and will test the
> media, but on the next step after that it says it can't find CD media.


How about if you dont verify the media ? Are you able to run the install ?

Also, try booting off the dvd media, and pull you tree over http, then
check when the installer starts what the state of media is on vc#2.

Finally, dont top post.

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

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Karanbir Singh]

On 28/06/2010 20:13, Emmanuel Noobadmin wrote:
> Has anybody tried or knows if it is possible to create a MD RAID1
> device using networked iSCSI devices like those created using
> OpenFiler?

I dont use openfiler, but I run a mdraid-10 ( which isnt raid10 ), off
locally mounted, remote storage exported over iscsi from centos-5 machines.

What did you try ? how did you fail ?

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

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Emmanuel Noobadmin]

On 6/29/10, Karanbir Singh  wrote:
> On 28/06/2010 20:13, Emmanuel Noobadmin wrote:
>> Has anybody tried or knows if it is possible to create a MD RAID1
>> device using networked iSCSI devices like those created using
>> OpenFiler?
>
> I dont use openfiler, but I run a mdraid-10 ( which isnt raid10 ), off
> locally mounted, remote storage exported over iscsi from centos-5 machines.
>
> What did you try ? how did you fail ?

I haven't tried it yet, still researching on which way to go (looked
into Lustre, then glusterFS, then now this). Coincidentally, I just
googled on your post in the mailing list archive and was about to ask
since your setup worked, wouldn't that implied that it should also
work with openfiler providing the iSCSI connection?

Or would openfiler even be necessary?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Karanbir Singh]

On 28/06/2010 20:31, Emmanuel Noobadmin wrote:
> I haven't tried it yet, still researching on which way to go (looked
> into Lustre, then glusterFS, then now this). Coincidentally, I just

Not sure what you are trying to do here. Lustre, glusterfs, gfs etc
solve a different problem than imported remote storage ( which is
essentially what iscsi will give you )

> googled on your post in the mailing list archive and was about to ask
> since your setup worked, wouldn't that implied that it should also
> work with openfiler providing the iSCSI connection?

I dont see why not. But you dont dont need openfilter to give you iscsi
capability. CentOS-5.1+ has had the ability to export an iscsi target
itself with all the tooling built in.

> Or would openfiler even be necessary?

Depends on what you want, perhaps
http://slimphpiscsipan.sourceforge.net/ might be all that is needed in
your case ? I prefer using tgtadm on the cli. It also means that I can
script my storage box's configs and wrap them into puppet manifests.

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

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Athmane Madjoudj]

>
> I dont see why not. But you dont dont need openfilter to give you iscsi
> capability. CentOS-5.1+ has had the ability to export an iscsi target
> itself with all the tooling built in.
>

AFAIK, Openfiler is  CentOS/rPath and has Web-based administration tool, 
this why some people use it.


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

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Les Mikesell]

On 6/28/2010 2:50 PM, Karanbir Singh wrote:
> On 28/06/2010 20:31, Emmanuel Noobadmin wrote:
>> I haven't tried it yet, still researching on which way to go (looked
>> into Lustre, then glusterFS, then now this). Coincidentally, I just
>
> Not sure what you are trying to do here. Lustre, glusterfs, gfs etc
> solve a different problem than imported remote storage ( which is
> essentially what iscsi will give you )

I think he is looking for redundant, failover remote storage (i.e. 
mirrored copies from different iscsi hosts).  Sort of like DRBD but with 
both copies remote.  I think is should work but the timing might be 
tricky on retries vs. failure on the iscsi connections.

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


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

Re: [CentOS] Upgrading MySQL

[Jakub Jedelský]

2010/6/28 Susan Day 

> Hi;
> I'm trying to install django and got this error:
>
> django.core.exceptions.ImproperlyConfigured: MySQLdb-1.2.1p2 or newer is
> required; you have 1.2.1
>
> So then I tried yum upgrade mysql and got this:
>
> No Packages marked for Update
>
> Please advise.
> TIA,
> Susan
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
>

Hi,

you can use package MySQL-python from CentOS Testing repo - there is newer
version (1.2.2) which works ok. I'm using it without any problems

-- 
Jakub Jedelský
e-mail: jakub.jedel...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] PHP version [SOLVED]

[Steve Lindemann]

Marcelo Roccasalva wrote:
>> On Fri, Jun 25, 2010 at 19:16, Steve Lindemann  wrote:
>> [...]
>> ...or directions for upgrading PHP from 5.1 to 5.2 on 64-bit (I found
>> directions for 32-bit)?
> 
> open /etc/yum.repos.d/CentOS-Testing.repo in your prefered editor and write:
> 
> #
> [c5-testing]
> name=CentOS-5 Testing
> baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/
> enabled=1
> gpgcheck=1
> gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing
> includepkgs=php*
> #


Thanks Marcelo - that did the trick nicely.
--
Steve

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

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Karanbir Singh]

On 28/06/2010 20:55, Les Mikesell wrote:
> I think he is looking for redundant, failover remote storage (i.e. 
> mirrored copies from different iscsi hosts).  Sort of like DRBD but with 
> both copies remote.  I think is should work but the timing might be 
> tricky on retries vs. failure on the iscsi connections.

yes, thats what I run. We import 5 remote iscsi connections that come
from 5 different hosts, and mdraid10 them locally on one machine - thats
our 'storage' box. Each of the 5 machines doing the iscsi target exports
run raid-0 themselves across 4 disks.

As long as latency is kept low, things work fine. The DM/MD stack works
fairly well even when individual block devices tend to have slightly
different traits. eg.  when you have a mix of 5900 and 7200 rpm disks in
the same machine.

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

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Emmanuel Noobadmin]

On 6/29/10, Karanbir Singh  wrote:
> On 28/06/2010 20:31, Emmanuel Noobadmin wrote:
>> I haven't tried it yet, still researching on which way to go (looked
>> into Lustre, then glusterFS, then now this). Coincidentally, I just
>
> Not sure what you are trying to do here. Lustre, glusterfs, gfs etc
> solve a different problem than imported remote storage ( which is
> essentially what iscsi will give you )

As my username suggests, I don't know what I'm doing. Server
admin/setup is secondary to my primary job of writing web-based
applications.

I'm trying to figure out a setup that would allow me to add VM guests
on more than two VM server and provide data redundancy to these
without having to add physical machines unnecessarily.

With just two machines, I could simply mirror them. But if I have more
VM guest than they can comfortably handle (or more than I am
comfortable), 3 servers seem a bit more tricky. Also if I need more
storage capacity than processing power, which is more usually the case
due to backup and history data, each physical server has a limit.

So I figured I might as well try to find a singular setup (less
administrative headache for the amateur admin) with a VM/data cluster
that can survive a single drive failure per machine as well as single
machine failure. I would then use this setup for the current client's
demand to try things out before the next one which will really need
the flexibility and redundancy.


> I dont see why not. But you dont dont need openfilter to give you iscsi
> capability. CentOS-5.1+ has had the ability to export an iscsi target
> itself with all the tooling built in.

I'm not sure yet since openFiler seems to provide a few more options,
if I'm not mistaken the ability to soft RAID 5/6 on multiple machines
and remote block duplication. So theoretically, I'm thinking with
openFiler presenting a frontend to the application servers, I could
increase storage without having to mess with the application server
setup.

i.e. they still see a pair of iSCSI from the openFiler servers, which
then RAID 5/6 iSCSI servers (physical or VM initially) to provide the
storage and can be increased at any time transparent to the
application servers.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Emmanuel Noobadmin]

On 6/29/10, Karanbir Singh  wrote:
> On 28/06/2010 20:55, Les Mikesell wrote:
>> I think he is looking for redundant, failover remote storage (i.e.
>> mirrored copies from different iscsi hosts).  Sort of like DRBD but with
>> both copies remote.  I think is should work but the timing might be
>> tricky on retries vs. failure on the iscsi connections.
>
> yes, thats what I run. We import 5 remote iscsi connections that come
> from 5 different hosts, and mdraid10 them locally on one machine - thats
> our 'storage' box. Each of the 5 machines doing the iscsi target exports
> run raid-0 themselves across 4 disks.

Part of my concern with such a setup is the whole data system goes
down too if the storage box dies due to say blown PSU or motherboard
problem. Doesn't it?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Can't install Centos with DVD on KVM.

[John R Pierce]

On 06/28/10 12:12 PM, cliff here wrote:
> still stumped.
>
> On Mon, Jun 28, 2010 at 9:51 AM, cliff here  > wrote:
>
> Subject line explains most of it
>
> I'm trying to install Centos from a dvd iso, that has been
> verified on KVM (Fedora 13) box.
>
> Virtual machine boots, and will launch anaconda and will test the
> media, but on the next step after that it says it can't find CD media.
>
>

FWIW, the verify ejected the virtual ISO when I ran an install on 
Vmware.  I had to remount it via the vmware management console before I 
could proceed






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

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Karanbir Singh]

On 28/06/2010 21:30, Emmanuel Noobadmin wrote:
> Part of my concern with such a setup is the whole data system goes
> down too if the storage box dies due to say blown PSU or motherboard
> problem. Doesn't it?

Depends on how you set it up, if you have 2 machines ( disk nodes ),
exporting iscsi. 1 machine ( data node ) doing the import and sets up a
raid1; you can afford to have one of those two machines down. You *cant*
afford to have the data-node down. Thats where the filesystem lives. You
can potentially have the same disks from the disk-nodes imported to a
standby data node using something like drbd over the mdraid setup.
Alternatively, you can look at using a clustered filesystem and have it
go X way. But then you may as well use something like gnbd with gfs2
instead(!).

Yes, lots of options and different ways of doing the same thing. So
start at the top, make a list of all the problems you are trying to
solve. then split that into 3 segments:
- Must have
- Good to have
- Dont really need

And then evaluate what solutions meet your requirements best.

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

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[John R Pierce]

On 06/28/10 12:13 PM, Emmanuel Noobadmin wrote:
> Has anybody tried or knows if it is possible to create a MD RAID1
> device using networked iSCSI devices like those created using
> OpenFiler?
>
> The idea I'm thinking of here is to use two OpenFiler servers with
> physical drives in RAID 1, to create iSCSI virtual devices and run
> CentOS guest VMs off the MD RAID 1 device. Since theoretically, this
> setup would survive both a single physical drive failure as well as a
> machine failure on the storage side with a much shorter failover time
> than say using heartbeat.
>

I considered much the same a couple years ago, its certainly doable 
But, after playing with it a bit in the lab, I moved onto something more 
robust...

the downside is A) iscsi on homebrew systems like openfiler tends to be 
less than rock solid reliable.  and B) upon a 'failure', the rebuild 
times will require remirroring the whole volume, which is going to take 
quite awhile across two iscsi targets.


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

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Emmanuel Noobadmin]

On 6/29/10, Karanbir Singh  wrote:
> Depends on how you set it up, if you have 2 machines ( disk nodes ),
> exporting iscsi. 1 machine ( data node ) doing the import and sets up a
> raid1; you can afford to have one of those two machines down. You *cant*
> afford to have the data-node down. Thats where the filesystem lives. You
> can potentially have the same disks from the disk-nodes imported to a
> standby data node using something like drbd over the mdraid setup.
> Alternatively, you can look at using a clustered filesystem and have it
> go X way. But then you may as well use something like gnbd with gfs2
> instead(!).

Looking up gfs2 was what lead me to glusterFS actually and because
glusterFS had all the RAID stuff pointed out upfront, I stopped
reading about gfs2. Googling gluster then lead to openFiler which then
seemed like a simpler way to achieve the objectives.

> Yes, lots of options and different ways of doing the same thing. So
> start at the top, make a list of all the problems you are trying to
> solve. then split that into 3 segments:
> - Must have
> - Good to have
> - Dont really need
>

Must have
- low cost, clients have a budget which was why mirroring all the
machines is not an option
- data redundancy, application servers can go down, but data must not
be lost/corrupted.
- expandable capacity
- works with VM
- doable by noob admin :D

Good to have
- able to add/restore capacity without need to take down the whole setup
- application server redundancy
- webUI for remote management

I've done mostly LVM + mdraid setup so far, hence the openfiler +
remote iSCSI raid route looks to fit the above and is the most simple
(less new things to learn/mess up) option compared to most other which
needs multiple components to work together it seems.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Les Mikesell]

On 6/28/2010 3:25 PM, Emmanuel Noobadmin wrote:
>
>> I dont see why not. But you dont dont need openfilter to give you iscsi
>> capability. CentOS-5.1+ has had the ability to export an iscsi target
>> itself with all the tooling built in.
>
> I'm not sure yet since openFiler seems to provide a few more options,
> if I'm not mistaken the ability to soft RAID 5/6 on multiple machines
> and remote block duplication. So theoretically, I'm thinking with
> openFiler presenting a frontend to the application servers, I could
> increase storage without having to mess with the application server
> setup.


If you are looking at openfiler, you might also want to consider 
nexentastor.  Their community edition is free for up to 12TB of storage. 
  It's an OpenSolaris/ZFS based system with web management, able to 
export cifs/nfs/ftp/sftp/iscsi with support for snapshots, 
deduplication, compression, etc.  I haven't used it beyond installing in 
a VM and going through some options, but it looks more capable than 
anything else I've seen for free.

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

Re: [CentOS] Upgrading MySQL

[Meenoo Shivdasani]

> django.core.exceptions.ImproperlyConfigured: MySQLdb-1.2.1p2 or newer is
> required; you have 1.2.1

To identify what package contains a specific file, you can use yum search.

For example:

yum search MySQLdb

returns

MySQL-python.x86_64 : An interface to MySQL

therefore MySQLdb can be updated by updating MySQL-python.

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

[CentOS] An Interview with Karan

[didi]

A nice little insight into CentOS :

http://distrowatch.com/weekly.php?issue=20100628#feature

Cheers Didi

p.s. Sorry if this has already been posted :)

-- 
Hoffmann Geerd-Dietger
http://contact.ribalba.de
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] centos5.5 text install forcing me to add all disks to LVM volgroup

[Dave]

Graphic installer doesn't like my graphics card, so I am using the text
installer. I have two physical disks in my system.

When I get to the "partitioning type" page, I choose "remove all partitions
on selected drives [etc]" and put an asterisk next to sda, no asterisk next
to sdb. I want to use sdb as a separate partition, no LVM, I figure I can
set it up after installing. Then I hit 'OK' and go to the warning page, say
yes. Review and modify partitioning layout - yes.

So now I am looking at the partitioning page and I am surprised to see
/dev/sdb and sdb1 down at the bottom, since that disk was *not* selected. I
select sdb1 and try to delete, it says " unable to delete You cannot delete
this partition: this parition is part of the LVM volume group 'volgroup00'".
If I try to delete /dev/sdb1, it says I must choose a partiton. If i try to
edit volgroup00, it says 'LVM volume groups can only be edited in the
graphical installer."

So, am I stuck? It seems like my only option is to go ahead and add both
disks, then try to remove one of the disks after completing the install. Is
there some sort of workaround for this?


What if I actually had some data on that drive (fortunately I do not), would
it get wiped by this?


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

Re: [CentOS] centos5.5 text install forcing me to add all disks to LVM volgroup

[Robert Heller]

At Mon, 28 Jun 2010 14:15:20 -1000 CentOS mailing list  
wrote:

> 
> 
> 
> Graphic installer doesn't like my graphics card, so I am using the text
> installer. I have two physical disks in my system.
> 
> When I get to the "partitioning type" page, I choose "remove all partitions
> on selected drives [etc]" and put an asterisk next to sda, no asterisk next
> to sdb. I want to use sdb as a separate partition, no LVM, I figure I can
> set it up after installing. Then I hit 'OK' and go to the warning page, say
> yes. Review and modify partitioning layout - yes.
> 
> So now I am looking at the partitioning page and I am surprised to see
> /dev/sdb and sdb1 down at the bottom, since that disk was *not* selected. I
> select sdb1 and try to delete, it says " unable to delete You cannot delete
> this partition: this parition is part of the LVM volume group 'volgroup00'".
> If I try to delete /dev/sdb1, it says I must choose a partiton. If i try to
> edit volgroup00, it says 'LVM volume groups can only be edited in the
> graphical installer."
> 
> So, am I stuck? It seems like my only option is to go ahead and add both
> disks, then try to remove one of the disks after completing the install. Is
> there some sort of workaround for this?

You should *manually* remove the partitions and *manually* partition
/dev/sda the way you want, with the basic set of file systems (/boot, /,
/home, etc.).  The defaults are just not appropriate for what you are
doing. 

> 
> 
> What if I actually had some data on that drive (fortunately I do not), would
> it get wiped by this?
> 
> 
> Mahalo,
> Dave
> 
> MIME-Version: 1.0
> 
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
> 
>

-- 
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software-- Linux Installation and Administration
http://www.deepsoft.com/  -- Web Hosting, with CGI and Database
hel...@deepsoft.com   -- Contract Programming: C/C++, Tcl/Tk



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

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Emmanuel Noobadmin]

On 6/29/10, Les Mikesell  wrote:

> If you are looking at openfiler, you might also want to consider
> nexentastor.  Their community edition is free for up to 12TB of storage.
>   It's an OpenSolaris/ZFS based system with web management, able to
> export cifs/nfs/ftp/sftp/iscsi with support for snapshots,
> deduplication, compression, etc.  I haven't used it beyond installing in
> a VM and going through some options, but it looks more capable than
> anything else I've seen for free.

Thanks for the info, it looks quite interesting and seems like a
simpler option given the claim of easy setup wizard doing things in 15
minutes.

The only problem is their HA is commercial only and costs more than
the entire hardware budget I've got for this. Crucially, it relies on
a failover/heartbeat kind of arrangement. According to some sources,
the failover delay of a few seconds will cause certain services/apps
to fail/lock up. Not an issue for the immediate need but will be a
major no no for the other project I have in the pipeline.

Which was why I was thinking of MD raid 1 on the application server
site: no failover delay if one of the data server fails to respond to
respond in time.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS 5.3 Xen installation trouble installing FUSE

[Eric B.]

Hi,

I've got CentOS 5.3 installed as a Xen client installed. I've recently been 
trying to install TrueCrypt on the VM, but am having miserable troubles with 
the Fuse kernel module.

To date, I've installed the following packages:
yum install truecrypt
yum install fuse

However, to launch the fuse module, I need the dkms_autoinstaller running. 
However, when I try to start the dkms_autoinstaller service I get the 
following error messages:

Jun 28 23:31:57 charliebrown dkms_autoinstaller: fuse (2.7.4-1.nodist.rf): 
Installing module on kernel 2.6.18-128.2.1.el5xen.
Jun 28 23:31:57 charliebrown dkms_autoinstaller: Kernel headers for 
2.6.18-128.2.1.el5xen are not installed. Cannot install this module.
Jun 28 23:31:57 charliebrown dkms_autoinstaller: Try installing 
linux-headers-2.6.18-128.2.1.el5xen or equivalent.

Indeed, the kernel modules available in yum are for 2.6.18-194.3.1.el5. I 
fished around, and found a kernel-headers package for 2.6.18-128.2.1.el5 
(http://137.138.246.63/cern/slc5X/x86_64/yum/updates/repoview/kernel-headers.html).

I downloaded the RPM, and downgraded my kernel-headers package. So I now 
have the kernel-headers package for 2.6.18-128.2.1.el5 installed. However, 
when I try to start the dkms_autoinstaller, I still get the same error 
message indicating that the Kernel headers for 2.6.18-128.2.1.el5xen are not 
installed.

Where can I find this package? They aren't on the Citrix repos. From the few 
threads I've read, ppl are suggested to download a DDK VM to build new 
modules, etc, but that still won't help me, as I need the headers on the 
actual machine to run the dkms_autoinstaller service.

I'm currently stuck / lost. Any help / suggestions would be greatly 
appreciated!

Thanks,

Eric 



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

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Christopher Chan]

On Tuesday, June 29, 2010 10:53 AM, Emmanuel Noobadmin wrote:
> On 6/29/10, Les Mikesell  wrote:
>
>> If you are looking at openfiler, you might also want to consider
>> nexentastor.  Their community edition is free for up to 12TB of storage.
>>It's an OpenSolaris/ZFS based system with web management, able to
>> export cifs/nfs/ftp/sftp/iscsi with support for snapshots,
>> deduplication, compression, etc.  I haven't used it beyond installing in
>> a VM and going through some options, but it looks more capable than
>> anything else I've seen for free.
>
> Thanks for the info, it looks quite interesting and seems like a
> simpler option given the claim of easy setup wizard doing things in 15
> minutes.
>
> The only problem is their HA is commercial only and costs more than
> the entire hardware budget I've got for this. Crucially, it relies on
> a failover/heartbeat kind of arrangement. According to some sources,
> the failover delay of a few seconds will cause certain services/apps
> to fail/lock up. Not an issue for the immediate need but will be a
> major no no for the other project I have in the pipeline.

So install Nexenta CP2/CP3 then. That's completely free and ZFS has its 
own web interface...
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Christopher Chan]

On Tuesday, June 29, 2010 04:53 AM, Emmanuel Noobadmin wrote:
> On 6/29/10, Karanbir Singh  wrote:
>> Depends on how you set it up, if you have 2 machines ( disk nodes ),
>> exporting iscsi. 1 machine ( data node ) doing the import and sets up a
>> raid1; you can afford to have one of those two machines down. You *cant*
>> afford to have the data-node down. Thats where the filesystem lives. You
>> can potentially have the same disks from the disk-nodes imported to a
>> standby data node using something like drbd over the mdraid setup.
>> Alternatively, you can look at using a clustered filesystem and have it
>> go X way. But then you may as well use something like gnbd with gfs2
>> instead(!).
>
> Looking up gfs2 was what lead me to glusterFS actually and because
> glusterFS had all the RAID stuff pointed out upfront, I stopped
> reading about gfs2. Googling gluster then lead to openFiler which then
> seemed like a simpler way to achieve the objectives.

No acls on Gluster...but I suppose you have no need for acl support...


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

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Emmanuel Noobadmin]

On 6/29/10, Christopher Chan  wrote:
>> The only problem is their HA is commercial only and costs more than
>> the entire hardware budget I've got for this. Crucially, it relies on
>> a failover/heartbeat kind of arrangement. According to some sources,
>> the failover delay of a few seconds will cause certain services/apps
>> to fail/lock up. Not an issue for the immediate need but will be a
>> major no no for the other project I have in the pipeline.
>
> So install Nexenta CP2/CP3 then. That's completely free and ZFS has its
> own web interface...

Sorry, a little braindead by now but how would the Nexenta Core
Platform (I assume this is the CP you are referring to), solve the
failover delay problem since it would still be relying on HB to do
failover monitoring right?

Or do you mean to use NCP for the storage units, relying on ZFS to do
the disk management and export iSCSI interfaces to the application to
use as MD RAID 1 members?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS MD RAID 1 on Openfiler iSCSI

[Les Mikesell]

Christopher Chan wrote:
> On Tuesday, June 29, 2010 10:53 AM, Emmanuel Noobadmin wrote:
>> On 6/29/10, Les Mikesell  wrote:
>>
>>> If you are looking at openfiler, you might also want to consider
>>> nexentastor.  Their community edition is free for up to 12TB of storage.
>>>It's an OpenSolaris/ZFS based system with web management, able to
>>> export cifs/nfs/ftp/sftp/iscsi with support for snapshots,
>>> deduplication, compression, etc.  I haven't used it beyond installing in
>>> a VM and going through some options, but it looks more capable than
>>> anything else I've seen for free.
>> Thanks for the info, it looks quite interesting and seems like a
>> simpler option given the claim of easy setup wizard doing things in 15
>> minutes.
>>
>> The only problem is their HA is commercial only and costs more than
>> the entire hardware budget I've got for this. Crucially, it relies on
>> a failover/heartbeat kind of arrangement. According to some sources,
>> the failover delay of a few seconds will cause certain services/apps
>> to fail/lock up. Not an issue for the immediate need but will be a
>> major no no for the other project I have in the pipeline.
> 
> So install Nexenta CP2/CP3 then. That's completely free and ZFS has its 
> own web interface...

Or 2 nexentastor (free community version) instances not configured for HA and 
do 
what you planned with MD raid with their iscsi targets.

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