FAQ
Interesting column at CNET...

http://news.cnet.com/8301-13505_3-10376762-16.html

~~
"Novell has been positioning itself as the Avis of Linux, a distant
but gaining Red Hat competitor that "tries harder." Like Oracle,
Novell argues that it can give customers Red Hat value at a lower
price.

"There's just one problem with this marketing spin: the "low-cost
alternative" to Red Hat isn't Novell. It's CentOS. And CentOS is free
as in $0.00.

"It's true that adoption of unpaid Linux like CentOS is booming, and
that this no-cost alternative to more expensive solutions like Red Hat
is a real threat to Red Hat. This is no doubt why Red Hat has made
"free-to-paid" a core element of its ongoing strategy, as related in
its recent earnings call.

"But it's a much bigger threat to Novell and Oracle, both of whom are
trying to position themselves as cheaper alternatives to Red Hat
Enterprise Linux."
~~

I wonder if Red Hat has ever considered limited, paid support options
for CentOS?

--
RonB -- Using CentOS 5.3

Search Discussions

  • Ian Blackwell at Oct 18, 2009 at 7:04 am

    Ron Blizzard wrote:
    I wonder if Red Hat has ever considered limited, paid support options
    for CentOS?
    I think that would be brand cannibalisation and self-defeating. To
    charge a lower support fee for the same product with a different name
    would surely only devalue their prime product and lead to revenue
    decreases in the long run.

    Hopefully there are and will remain to be enough businesses who support
    Red Hat. I know most of my customers would not be comfortable with a
    community support arrangement and so pay Red Hat's subscription fees.
    Thank goodness they do, because without them we wouldn't have CentOS.

    Ian
  • Ron Blizzard at Oct 18, 2009 at 9:53 am

    On Sun, Oct 18, 2009 at 2:04 AM, Ian Blackwell wrote:
    Ron Blizzard wrote:
    I wonder if Red Hat has ever considered limited, paid support options
    for CentOS?
    I think that would be brand cannibalisation and self-defeating. ?To
    charge a lower support fee for the same product with a different name
    would surely only devalue their prime product and lead to revenue
    decreases in the long run.
    You're right, of course. I didn't think it out.
    Hopefully there are and will remain to be enough businesses who support
    Red Hat. ?I know most of my customers would not be comfortable with a
    community support arrangement and so pay Red Hat's subscription fees.
    Thank goodness they do, because without them we wouldn't have CentOS.
    I'm pretty sure most corporations will continue to pay to use Red Hat.
    It's pretty tough to go the head of IT and tell them you want to use
    an OS without a corporate support license. Support is a security
    blanket, if nothing else -- and it's a place to lay blame if something
    goes wrong. (Though there are some exceptions.)

    CentOS has its niche -- pretty big "niche" actually.

    --
    RonB -- Using CentOS 5.3
  • Kwan Lowe at Oct 18, 2009 at 12:17 pm

    I'm pretty sure most corporations will continue to pay to use Red Hat.
    It's pretty tough to go the head of IT and tell them you want to use
    an OS without a corporate support license. Support is a security
    blanket, if nothing else -- and it's a place to lay blame if something
    goes wrong. (Though there are some exceptions.)
    If my company is in any way representative, then RedHat has nothing to
    fear from CentOS. Though a few of the engineers use CentOS as
    workstations or POC machines, our policy is that we have commercial
    support of our production software. We have run into issues with other
    applications that are no longer under support.

    CentOS has actually played a large role in getting RedHat into our
    environment. Without the ability to demo POCs, I think it would be
    unlikely that we would have tried Linux.

    (I of course am not speaking for my company in any way.)
  • Ken at Oct 18, 2009 at 2:50 pm

    On 10/18/2009 08:17 AM Kwan Lowe wrote:
    I'm pretty sure most corporations will continue to pay to use Red Hat.
    It's pretty tough to go the head of IT and tell them you want to use
    an OS without a corporate support license. Support is a security
    blanket, if nothing else -- and it's a place to lay blame if something
    goes wrong. (Though there are some exceptions.)
    If my company is in any way representative, then RedHat has nothing to
    fear from CentOS. Though a few of the engineers use CentOS as
    workstations or POC machines, our policy is that we have commercial
    support of our production software. We have run into issues with other
    applications that are no longer under support.

    CentOS has actually played a large role in getting RedHat into our
    environment. Without the ability to demo POCs, I think it would be
    unlikely that we would have tried Linux.

    (I of course am not speaking for my company in any way.)
    I'm a contractor for an organization which has three linux servers, one
    of which is a high-profile, highly mission-critical production machine,
    the second of which is a development machine due to replace the first
    within the month. The third is an experimental development machine
    which I built and alone am doing development on. The first two run
    Redhat, the third runs CentOS.

    In the couple of months I've had the need to contact Redhat support on
    just one issue and their "support" has been terrible, so far completely
    useless and a waste of time. I don't know what Redhat charges us for
    support, but whatever it is, it hasn't been worth it. I even went so
    far as to express this to others in the department and have a private
    conversation with the head of the department (my boss's boss),
    expressing my disappointment with redhat support to him.

    If my (admittedly brief) experience is any indication, if redhat's lead
    in the linux world is based on their support, their position is very
    tenuous.
  • Amos Shapira at Oct 19, 2009 at 9:52 am

    2009/10/19 ken <gebser at mousecar.com>:
    In the couple of months I've had the need to contact Redhat support on
    just one issue and their "support" has been terrible, so far completely
    useless and a waste of time. ?I don't know what Redhat charges us for
    The only guy I personally know who went with RedHat "because their
    support was included for free with our servers" reported the same.

    I'm a bit surprised (and disappointed) to hear such negative
    testimonials about RedHat support.

    Do others have different experience?

    Could it be the the quality of support is tiered by how much you pay,
    enough to make a difference?

    Personally - my organisation runs over a hundred CentOS servers and
    growing rapidly, so for now it's not directly relevant to us. But I am
    aware of the connection between RedHat's health and CentOS', as well
    as RedHat's large volume of contribution back to the FOSS world, and
    would like to see them do well.

    Cheers,

    --Amos
  • Rainer Duffner at Oct 19, 2009 at 10:04 am

    Amos Shapira schrieb:
    2009/10/19 ken <gebser at mousecar.com>:
    In the couple of months I've had the need to contact Redhat support on
    just one issue and their "support" has been terrible, so far completely
    useless and a waste of time. I don't know what Redhat charges us for
    The only guy I personally know who went with RedHat "because their
    support was included for free with our servers" reported the same.

    I'm a bit surprised (and disappointed) to hear such negative
    testimonials about RedHat support.

    Do others have different experience?

    Could it be the the quality of support is tiered by how much you pay,
    enough to make a difference?

    I think the end-result may be just that, but for a different reason than
    one may think.

    Note that I don't have a deeper insight into what actually goes on at
    RedHat, but this is what I think happens, based on my own observations
    supporting customers.

    If you are a large customer, you open cases more often and maybe even
    have dedicated support-staff.
    After a while, that staff knows the way around your hardware, your
    network and gets a feeling for where the problem may lie.
    It's incredibly difficult to diagnose a problem with just the few lines
    you usually get from a support-ticket - I dare say almost impossible.
    Also, of course, with a larger contract, you may get to 2nd and
    3rd-level support easier/quicker.



    Best Regards,
    Rainer
  • Clint Dilks at Oct 19, 2009 at 8:12 pm

    Rainer Duffner wrote:
    Amos Shapira schrieb:
    2009/10/19 ken <gebser at mousecar.com>:

    In the couple of months I've had the need to contact Redhat support on
    just one issue and their "support" has been terrible, so far completely
    useless and a waste of time. I don't know what Redhat charges us for
    The only guy I personally know who went with RedHat "because their
    support was included for free with our servers" reported the same.

    I'm a bit surprised (and disappointed) to hear such negative
    testimonials about RedHat support.

    Do others have different experience?http://download.openoffice.org/other.html#en-US

    Could it be the the quality of support is tiered by how much you pay,
    enough to make a difference?

    I think the end-result may be just that, but for a different reason than
    one may think.

    Note that I don't have a deeper insight into what actually goes on at
    RedHat, but this is what I think happens, based on my own observations
    supporting customers.

    If you are a large customer, you open cases more often and maybe even
    have dedicated support-staff.
    After a while, that staff knows the way around your hardware, your
    network and gets a feeling for where the problem may lie.
    It's incredibly difficult to diagnose a problem with just the few lines
    you usually get from a support-ticket - I dare say almost impossible.
    Also, of course, with a larger contract, you may get to 2nd and
    3rd-level support easier/quicker.



    Best Regards,
    Rainer

    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    My Experience has been that its the difference between installing system
    and setting up systems for production use. In New Zealand at least it
    seems that if you can have a system where everything is installed in the
    standard way with a default configuration then you can get assistance.
    If your installation varies from this at all, the first statement is we
    won't / can't help until you move to the standard default configuration.
  • Ray Van Dolson at Oct 19, 2009 at 8:19 pm

    On Tue, Oct 20, 2009 at 09:12:01AM +1300, Clint Dilks wrote:
    Rainer Duffner wrote:
    Amos Shapira schrieb:
    2009/10/19 ken <gebser at mousecar.com>:

    In the couple of months I've had the need to contact Redhat support on
    just one issue and their "support" has been terrible, so far completely
    useless and a waste of time. I don't know what Redhat charges us for
    The only guy I personally know who went with RedHat "because their
    support was included for free with our servers" reported the same.

    I'm a bit surprised (and disappointed) to hear such negative
    testimonials about RedHat support.

    Do others have different experience?http://download.openoffice.org/other.html#en-US

    Could it be the the quality of support is tiered by how much you pay,
    enough to make a difference?
    As long as we're sharing anecdotal stories... my experiences have
    typically been really really good with RH Support.

    Perhaps our issues were atypical in that most of them were well
    troubleshot locally ahead of time, software bug type issues. We
    typically had a BZ already open and were able to escalate to engineers
    and get a lot of high quality give and take both in the SR and the BZ.

    The first line of support I can imagine would be fairly typical in that
    you'll be asked to try a lot of basic things first that may seem
    trivial and insulting...

    Ray
  • Niki Kovacs at Oct 19, 2009 at 8:19 pm

    Clint Dilks a ?crit :

    My Experience has been that its the difference between installing system
    and setting up systems for production use. In New Zealand at least it
    seems that if you can have a system where everything is installed in the
    standard way with a default configuration then you can get assistance.
    If your installation varies from this at all, the first statement is we
    won't / can't help until you move to the standard default configuration.
    I was recently called by a small local company (20 employees) who run
    Linux: Slackware on the server, and Ubuntu on the desktops. The company
    had "a few issues with the server" (setup by the boss himself, who
    didn't have the spare time to maintain the thing).

    I took a peek at that thing. In short, it's a Slackware 11.0, a bare
    minimum install, and then about everything from Apache to PostgreSQL to
    whatever compiled by hand, not even with build scripts, but manually
    with ./configure (--prefix=...... [options]), make, make install,
    installed once and then never touched again.

    I said: "Erm, sorry, but, well, no."

    :o)

    Niki
  • Clint Dilks at Oct 19, 2009 at 8:35 pm

    Niki Kovacs wrote:
    Clint Dilks a ?crit :

    My Experience has been that its the difference between installing system
    and setting up systems for production use. In New Zealand at least it
    seems that if you can have a system where everything is installed in the
    standard way with a default configuration then you can get assistance.
    If your installation varies from this at all, the first statement is we
    won't / can't help until you move to the standard default configuration.
    I was recently called by a small local company (20 employees) who run
    Linux: Slackware on the server, and Ubuntu on the desktops. The company
    had "a few issues with the server" (setup by the boss himself, who
    didn't have the spare time to maintain the thing).

    I took a peek at that thing. In short, it's a Slackware 11.0, a bare
    minimum install, and then about everything from Apache to PostgreSQL to
    whatever compiled by hand, not even with build scripts, but manually
    with ./configure (--prefix=...... [options]), make, make install,
    installed once and then never touched again.

    I said: "Erm, sorry, but, well, no."

    :o)

    Niki
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    And that is completely understandable but my point is with a support
    contract you arrange yourself with some company both parties agree to
    what is covered and what isn't. So you know when you are going outside
    of your support arrangements and deal with things accordingly. In the
    case of Red Hat it can take time to understand what the boundaries are.
    You can also run into the issue of Management assuming that paid support
    means support for everything.

    In my case I have always working in Research or Academic environments
    and there is no way that a default build can meet production needs.
  • John R Pierce at Oct 19, 2009 at 8:39 pm

    Clint Dilks wrote:
    My Experience has been that its the difference between installing system
    and setting up systems for production use. In New Zealand at least it
    seems that if you can have a system where everything is installed in the
    standard way with a default configuration then you can get assistance.
    If your installation varies from this at all, the first statement is we
    won't / can't help until you move to the standard default configuration.

    which is about as useful as Microsoft Windows support... is it broken?
    "reinstall windows"....
  • Joseph L. Casale at Oct 19, 2009 at 8:45 pm

    which is about as useful as Microsoft Windows support... is it broken?
    "reinstall windows"....
    FFS, this attitude amongst opensource guys that MS is the devil and are
    trying to murder your family or sabotage your life is such BS.

    Take the Tin Foil Hat off and settle down, MS support is easily on par w/
    or *the* best support there is.

    I maintain both Linux/Unix and Windows machines, and since high school days
    I have been using PSS and there is nothing like it. They have have *ALWAYS*
    fixed everything but one issue I have had, where that one issue I resolved
    before them.

    Spreading your FUD reflects on _you_ not MS.

    I love Linux (and prefer to toil in this forest) but don't preach that anti-ms
    crap, its utter malarkey.

    Geesh...
  • Les Mikesell at Oct 19, 2009 at 9:11 pm

    Joseph L. Casale wrote:
    which is about as useful as Microsoft Windows support... is it broken?
    "reinstall windows"....
    FFS, this attitude amongst opensource guys that MS is the devil and are
    trying to murder your family or sabotage your life is such BS.
    The people with the the attitude probably acquired it naturally by
    trying to run something earlier than about Windows 2000 SP2. Or NT SP6a
    (its very last update).
    Take the Tin Foil Hat off and settle down, MS support is easily on par w/
    or *the* best support there is.
    Maybe today. How long has it been that you could start something on a
    windows box and expect it to still be running a year later? People
    runing unix/linux have expected and achieved that for decades.
    I maintain both Linux/Unix and Windows machines, and since high school days
    I have been using PSS and there is nothing like it.
    How long has that been?
    They have have *ALWAYS*
    fixed everything but one issue I have had, where that one issue I resolved
    before them.

    Spreading your FUD reflects on _you_ not MS.

    I love Linux (and prefer to toil in this forest) but don't preach that anti-ms
    crap, its utter malarkey.
    If you forget history, you are doomed to repeat it.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Joseph L. Casale at Oct 19, 2009 at 9:50 pm

    Maybe today. How long has it been that you could start something on a
    windows box and expect it to still be running a year later? People
    runing unix/linux have expected and achieved that for decades.
    A long time:)
    Windows _is_ reliable, what isn't reliable is the myriad of cheap sh!t
    hardware some people expect to work and cheap sh!t software some people
    wonder why windows runs poorly with.

    Linux breaks just as hard with bad software.
    How long has that been?
    Maybe 15 years?
    If you forget history, you are doomed to repeat it.
    Well, I have never had bad history with windows since nt3.51 or nt4 days.
    It broke when I did stupid things, but ran for a long time when I had
    good hardware and knew what I was doing. Thankfully my history is repeating
    itself:) I've had a 2003 DC running at one place for so many years, I cant
    even begin to imagine when that thing was put in service. It hum's right along
    side some sun & centos machines:)

    jlc
  • Les Mikesell at Oct 19, 2009 at 11:32 pm

    Joseph L. Casale wrote:
    Maybe today. How long has it been that you could start something on a
    windows box and expect it to still be running a year later? People
    runing unix/linux have expected and achieved that for decades.
    A long time:)
    Windows _is_ reliable, what isn't reliable is the myriad of cheap sh!t
    hardware some people expect to work and cheap sh!t software some people
    wonder why windows runs poorly with.

    Linux breaks just as hard with bad software.
    How long has that been?
    Maybe 15 years?
    If you forget history, you are doomed to repeat it.
    Well, I have never had bad history with windows since nt3.51 or nt4 days.
    It broke when I did stupid things, but ran for a long time when I had
    good hardware and knew what I was doing.
    You must have never done much with NT or pre-SP2 win2k. I couldn't keep
    it running with our applications for more than a week or so at a time.
    After NT SP6a and Win2k SP2, things got much, much better with no change
    in the application load or hardware, so you can't tell me the OS wasn't
    buggy back then.
    Thankfully my history is repeating
    itself:) I've had a 2003 DC running at one place for so many years, I cant
    even begin to imagine when that thing was put in service. It hum's right along
    side some sun & centos machines:)
    Yes, 2003 is OK. But I've still got a box running RedHat 7.3 from way
    before that that has never crashed and has had uptimes as long as 4
    years (had to shut it down to move it a few times).

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Rob Townley at Oct 20, 2009 at 3:10 am

    On Mon, Oct 19, 2009 at 3:45 PM, Joseph L. Casale wrote:
    which is about as useful as Microsoft Windows support... is it broken?
    "reinstall windows"....
    FFS, this attitude amongst opensource guys that MS is the devil and are
    trying to murder your family or ?sabotage your life is such BS.

    Take the Tin Foil Hat off and settle down, MS support is easily on par w/
    or *the* best support there is.
    i don't believe the statement lambastes MS because "is about as
    useful" means about the same.

    Remember that windows integration website ( don't remember the name
    but related to nLite and ryanvm) shutdown by Microsoft - it made a
    great deal of news because they had scripts to take out annoyances
    such as balloons popping up in the taskbar. MS lawyers had them
    disbanded. MS Tech Support asked customers to wipe and reinstall, but
    when the "Wireless Networks Found" balloon didn't pop up, they knew
    some things had been changed in the windows installation because they
    just had the customer wipe and reinstall. The point i believe the
    original poster was making is that "wipe-n-reinstall" is very very
    very common everywhere even at MS.

    i have been running NT since 3.0? / 3.1 and wondered why anything but
    NT ever came out. i don't think MS is evil but i have wasted too much
    time swapping legitimate MS Office CDs when there were multiple MS
    Office versions installed.

    It takes way too much time to install a windows system from scratch,
    configure how you want it, and then install all the apps on top and
    then all the updates and then all the updates to the apps ad nauseam.
    Oh, you want to image that harddrive now? Well you get 3 attempts
    with sysprep and then you start all over - no thanks.

    There is no comparison to 'yum -y update' -- i have wasted way too
    much of my life updating software, hunting down product keys (the COA
    on the pc case is hidden under the lock or on a misplaced cd). In
    fact, depending on which method you get to the 2008R2 activation
    screen it will not take your key. Dealing with proprietary phone tech
    support regarding software bugs that i could fix myself if i had the
    code - it is demeaning. In that world, you rarely have an opportunity
    to talk to the programmer, let alone a good tech.

    Filing a bug report in Bugzilla and getting a response from one of the
    programmers directly responsible - that has happened to me in open
    source. Never happened once as a Win32 developer and user. There
    really is no long lasting great tech support except open source along
    with the skill and intelligence we have ourselves and shared over the
    internet. i am more independent that way. i have more freedom that
    way. i have more time.
    I maintain both Linux/Unix and Windows machines, and since high school days
    I have been using PSS and there is nothing like it. They have have *ALWAYS*
    fixed everything but one issue I have had, where that one issue I resolved
    before them.

    Spreading your FUD reflects on _you_ not MS.

    I love Linux (and prefer to toil in this forest) but don't preach that anti-ms
    crap, its utter malarkey.

    Geesh...

    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • Joseph L. Casale at Oct 20, 2009 at 11:47 am

    Remember that windows integration website ( don't remember the name
    but related to nLite and ryanvm) shutdown by Microsoft - it made a
    great deal of news because they had scripts to take out annoyances
    such as balloons popping up in the taskbar. MS lawyers had them
    disbanded
    For a good reason, because silly non-admins where using nlite in a corporate
    environment? WTF, if you take all of RHELS rpms and recompile them in an
    unsupported manor then call for help, what do you think they will do?

    You have got to be kidding me, ms should just support anything anyone wants
    to do? Sigh...
    It takes way too much time to install a windows system from scratch, configure
    how you want it, and then install all the apps on top and then all the updates
    and then all the updates to the apps ad nauseam. Oh, you want to image that
    harddrive now? Well you get 3 attempts with sysprep and then you start all
    over - no thanks..
    Well, if you need some guidance on how to do this, I would be willing to help.
    Even at home I use RIS/WDS and deploy almost all of my apps to windows lab vm's
    with GPO's. So, unfortunately yes, I do *completely* automated deployments that
    setup all my apps and even pre-populate some settings at the push of F12. When
    I didn't have this knowledge, I never assumed Bill was an a$$hole, I took the
    time to learn it. Same with Linux, when I never had kickstart knowledge and
    couldn't automate my CentOS deployments, I never assumed KB or the CentOS devs
    were scumbags, I took the time to learn it:)

    Guess what, now I can do both! Wow...

    This useless thread will never end, FOSS guys have their sh!t in a knot over
    MS for reason of which I have my own opinions. Bottom line is, I work with both
    and quit successfully get equivalent uptimes and QOS with both. Many guys do it,
    it's possible. I met one of the guys who did the barnes and noble setup at an msdn
    conference, I guess that successful setup wasn't the result of competent guys
    who actually knew their sh!t and did a good job, but just dumb luck. Mama always
    said if I could be smart or lucky, it was better to be lucky:)

    jlc
  • Joshua Baker-LePain at Oct 20, 2009 at 12:10 pm
    On Tue, 20 Oct 2009 at 11:47am, Joseph L. Casale wrote

    <I can't believe I'm jumping into this thread>
    This useless thread will never end, FOSS guys have their sh!t in a knot
    over MS for reason of which I have my own opinions.
    I wonder what those opinions are. One of the main reasons *I* am no fan
    of MS is their clear subversion of standards for their own ends.
    Exchange, e.g., has a *horrible* IMAP implementation which they have point
    blank admitted they have no intentions of fixing. They, of course, want
    you to use their proprietary mail client. And then there was the whole
    ODF fiasco.

    I hear they make good mice though...

    --
    Joshua Baker-LePain
    QB3 Shared Cluster Sysadmin
    UCSF
  • Joseph L. Casale at Oct 20, 2009 at 2:02 pm

    I wonder what those opinions are.
    That would just start a useless flame..
    One of the main reasons *I* am no fan
    of MS is their clear subversion of standards for their own ends.
    Well, they do some stupid things. No Linux vendor ever did?[1]
    Exchange, e.g., has a *horrible* IMAP implementation which they have point
    blank admitted they have no intentions of fixing.
    And I hope they don't:) It's a sh!t protocol, OL is by far the best
    client I have used. I am actually rdp'ing into a windows wkst to use ol
    from my linux desktop as I have yet to find a client as feature-full
    *and* stable is outlook. The Outlook anywhere with rpc/http, activesync
    and OWA is a corporate dream to work with imho.
    And then there was the whole ODF fiasco.
    Yup, a spade is a spade, that was useless as mams on a bull. See [1] :)
    I hear they make good mice though...
    Heh, they're ok...
  • Rob Townley at Oct 21, 2009 at 7:06 am

    On Tue, Oct 20, 2009 at 6:47 AM, Joseph L. Casale wrote:
    Remember that windows integration website ( don't remember the name
    but related to nLite and ryanvm) shutdown by Microsoft - it made a
    great deal of news because they had scripts to take out annoyances
    such as balloons popping up in the taskbar. ?MS lawyers had them
    disbanded
    For a good reason, because silly non-admins where using nlite in a corporate
    environment? WTF, if you take all of RHELS rpms and recompile them in an
    unsupported manor then call for help, what do you think they will do?

    You have got to be kidding me, ms should just support anything anyone wants
    to do? Sigh...
    The point was that there were at least thousands of publicly
    documented instances of the first line of support was to wipe n
    reinstall. Should users have to wait 9 years to get some balloons
    turned off? The changes were registry key changes documented by MS,
    not exactly recompiles.

    No, i don't think MS should have to support nLite modifications, but
    wouldn't the money spent on lawyers have been better spent on giving
    customers what they wanted. And when one stops and thinks about src
    rpms .....
    It takes way too much time to install a windows system from scratch, configure
    how you want it, ?and then install all the apps on top and then all the updates
    and then all the updates to the apps ad nauseam. Oh, you want to image that
    harddrive now? ?Well you get 3 attempts with sysprep and then you start all
    over - no thanks..
    Well, if you need some guidance on how to do this, I would be willing to help.
    Even at home I use RIS/WDS and deploy almost all of my apps to windows lab vm's
    with GPO's. So, unfortunately yes, I do *completely* automated deployments that
    setup all my apps and even pre-populate some settings at the push of F12. When
    I didn't have this knowledge, I never assumed Bill was an a$$hole, I took the
    time to learn it. Same with Linux, when I never had kickstart knowledge and
    couldn't automate my CentOS deployments, I never assumed KB or the CentOS devs
    were scumbags, I took the time to learn it:)
    'yum repolist' lists 19,107 packages i can install in a heartbeat.
    How many 3rd party apps do you actually install? How many windows
    packages do you have to spend _time_ repackaging with a $1500 and
    $more windows MSI installer package to get it pushed out correctly
    with standard gpos? For the non MSI apps, how long did it take to
    contact the developer and hunt down the parameters to answer yes,yes,
    product-key=XXX-ZG123-56787-01l1l1Il (r those ones, letter i, letter
    L, zeros?).

    i never thought of Bill in a negative light. i didn't downgrade to
    WinXP and deployed WinVista except to all but my workstations. A MS
    technical account executive is giving a breakfast security meeting in
    6 hours where i live on why patch management is a big problem that
    will NOT be going away. Maybe MS will come out with something akin
    to yum.repos app store, but it will never have all the proprietary
    software you will need and oh yeah - it will cost money over and over.
    Guess what, now I can do both! Wow...
    Guess what, i can too. How many families can afford the licensing
    fees for a windows server at home? Why not use OCSinventory-ng or
    FreeGhost? Winner?
    This useless thread will never end, FOSS guys have their sh!t in a knot over
    MS for reason of which I have my own opinions. Bottom line is, I work with both
    and quit successfully get equivalent uptimes and QOS with both. Many guys do it,
    it's possible. I met one of the guys who did the barnes and noble setup at an msdn
    conference, I guess that successful setup wasn't the result of competent guys
    who actually knew their sh!t and did a good job, but just dumb luck. Mama always
    said if I could be smart or lucky, it was better to be lucky:)
    You may even get longer uptimes with MS, but how much time do you have
    to spend patching all those 3rd party applications? All those apps
    developed by the vast majority of developers that believe that if
    their install process is half as good as MS Office, we're golden.
    Those other users of MSDN that still require their users to have full
    admin privs bc that is how we developed the software because the MS
    developer tools required Administrator privileges to compile the exe?
    Those same MSDN developers that do not see anything wrong with web
    browsing with admin privileges. i have been using NTFS permissions
    since the mid 90's and just last Friday had to explain to one of our
    vendor's overpaid, MSDN reading C# experts the concept of 'Least
    Privilege'.

    i have read and enjoyed many of your posts Joe, consider unwinding
    some of those knots, the cussing doesn't help.
    jlc

    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • Ron Blizzard at Oct 20, 2009 at 7:57 am

    On Mon, Oct 19, 2009 at 3:45 PM, Joseph L. Casale wrote:
    which is about as useful as Microsoft Windows support... is it broken?
    "reinstall windows"....
    FFS, this attitude amongst opensource guys that MS is the devil and are
    trying to murder your family or ?sabotage your life is such BS.
    I don't know what Microsoft's support is like for servers, but on the
    desktop they *definitely* tell you to reinstall for almost any major
    problem. I don't work on computers for a living anymore, but my wife
    is always telling people that I can help them when their Windows
    computers go down. An older lady at our church had a Vista machine go
    KSOD (black screen of death on her). It was a fairly new Dell. I
    called them and explained to them that I couldn't get it to boot --
    they gave me instructions on reinstalling. Microsoft's support
    suggestion was to reinstall. I found out later why, there must have
    been 10 different ways to fix KSOD (that worked for some people but
    not others) and I tried every one. Finally using MSCONFIG I was able
    to open a "hive" (I've purposely avoided Vista so this is all new to
    me) and backed up the user directories to a portable hard drive. And
    then I did what I almost always have to do with Windows... reinstalled
    it. The KSOD "event" occurred after an automatic Windows update (which
    isn't all that uncommon I found out).
    Take the Tin Foil Hat off and settle down, MS support is easily on par w/
    or *the* best support there is.
    Again, telling you to "reinstall" is not good support, in my opinion.
    I maintain both Linux/Unix and Windows machines, and since high school days
    I have been using PSS and there is nothing like it. They have have *ALWAYS*
    fixed everything but one issue I have had, where that one issue I resolved
    before them.
    Okay, what did they tell you about KSOD? Even if I can't fix it, I
    would at least like to know what really causes it. (There are a lot of
    theories out there.)
    Spreading your FUD reflects on _you_ not MS.
    All he said is that they tell you to "reinstall" which is what they
    do. It's not FUD.
    I love Linux (and prefer to toil in this forest) but don't preach that anti-ms
    crap, its utter malarkey.
    Seems to me you're a little bit too sensitive here. I've reinstalled
    Windows on many personal computers for friends and family, and have
    seen many Windows computers "re-imaged" in the corporate environment.
    "Reboot" and/or "reinstall" are two of the most common "fixes" for
    Windows. This is not "tin-hat" malarkey, it's the simple truth -- and
    it's one of the big reasons I moved to Linux.

    --
    RonB -- Using CentOS 5.3
  • Joseph L. Casale at Oct 20, 2009 at 11:47 am

    I called them and explained to them that I couldn't get it to boot --
    they gave me instructions on reinstalling
    So Windows is garbage because one support tech is an idiot? There are
    no idiots in the Linux world?
    The KSOD "event" occurred after an automatic Windows update (which
    isn't all that uncommon I found out).
    I have never had a bsod after windows update in 15 years? But then again,
    I test all my updates in a lab environment before my WSUS server pushes
    them out on mass.
    Okay, what did they tell you about KSOD? Even if I can't fix it, I
    would at least like to know what really causes it. (There are a lot of
    theories out there.)
    It wasn't a BSOD, it was high IO across a set of spindles with VSS "enabled
    and setup wrong" by my corp. What the entry tech (as it wasn't yet elevated)
    didn't know was specific details about how my fileserver was utilized which
    had an impact in my scenario. A seasoned colleague on the list who *just*
    went through it all gave me the tip.

    I guess all Linux techs start out at Datacenter level:)
    Seems to me you're a little bit too sensitive here.
    You're right, because that BS was just MS hate, not fact.
    jlc
  • Ron Blizzard at Oct 20, 2009 at 7:53 pm

    On Tue, Oct 20, 2009 at 6:47 AM, Joseph L. Casale wrote:
    I called them and explained to them that I couldn't get it to boot --
    they gave me instructions on reinstalling
    So Windows is garbage because one support tech is an idiot? There are
    no idiots in the Linux world?
    Support techs usually look up problems in the support database. But if
    you know of an official Microsoft fix for KSOD, I would be happy to
    take a look at it.
    The KSOD "event" occurred after an automatic Windows update (which
    isn't all that uncommon I found out).
    I have never had a bsod after windows update in 15 years? But then again,
    I test all my updates in a lab environment before my WSUS server pushes
    them out on mass.
    Again, I think you're talking about Windows in a server environment
    rather than on the Desktop. Two different animals. Google "KSOD" some
    time.
    Okay, what did they tell you about KSOD? Even if I can't fix it, I
    would at least like to know what really causes it. (There are a lot of
    theories out there.)
    It wasn't a BSOD, it was high IO across a set of spindles with VSS "enabled
    and setup wrong" by my corp. What the entry tech (as it wasn't yet elevated)
    didn't know was specific details about how my fileserver was utilized which
    had an impact in my scenario. A seasoned colleague on the list who *just*
    went through it all gave me the tip.

    I guess all Linux techs start out at Datacenter level:)
    And, if you're an individual user, that's all the higher you're going
    to get. Thing is, if there is a solid fix for KSOD, Microsoft should
    publish it on their web site. Again, you're talking about server
    issues -- so it's like comparing apples to oranges.
    Seems to me you're a little bit too sensitive here.
    You're right, because that BS was just MS hate, not fact.
    I didn't see the hate. I saw reality. I *often* see "reinstall" given
    as the final fix for Windows issues. I hope (am pretty sure) that's
    not the "fix" they give you on Microsoft servers, but it's definitely
    the "fix" you're given on Microsoft desktops.

    --
    RonB -- Using CentOS 5.3
  • Eugene Vilensky at Oct 19, 2009 at 8:31 pm
    On Sun, Oct 18, 2009 at 9:50 AM, ken wrote:
    ....
    In the couple of months I've had the need to contact Redhat support on
    just one issue and their "support" has been terrible, so far completely
    useless and a waste of time.
    ..
    I've opened the lowest-severity cases and generally can express the
    same frustration. I have also opened a high-severity case and talked
    to a very knowledgeable engineer with all kinds of cross-functional
    storage experience.

    My biggest frustration is they are very aggressive at triaging our
    cases (we are an academic subscription customer, we pay much less but
    only a few machines are covered by the commercial SLAs) down to the
    lowest severity possible unless we yell loudly that we are down.

    But, fwiw, I've had the above experience with IBM, HDS, and Cisco.
    It's a script that we follow until we yell loud enough at the right
    people. IBM probably being the worst.
  • Ian Blackwell at Oct 19, 2009 at 9:59 pm

    ken wrote:
    On 10/18/2009 08:17 AM Kwan Lowe wrote:

    I'm pretty sure most corporations will continue to pay to use Red Hat.
    It's pretty tough to go the head of IT and tell them you want to use
    an OS without a corporate support license. Support is a security
    blanket, if nothing else -- and it's a place to lay blame if something
    goes wrong. (Though there are some exceptions.)
    If my company is in any way representative, then RedHat has nothing to
    fear from CentOS. Though a few of the engineers use CentOS as
    workstations or POC machines, our policy is that we have commercial
    support of our production software. We have run into issues with other
    applications that are no longer under support.

    CentOS has actually played a large role in getting RedHat into our
    environment. Without the ability to demo POCs, I think it would be
    unlikely that we would have tried Linux.

    (I of course am not speaking for my company in any way.)
    In the couple of months I've had the need to contact Redhat support on
    just one issue and their "support" has been terrible, so far completely
    useless and a waste of time. I don't know what Redhat charges us for
    support, but whatever it is, it hasn't been worth it. I even went so
    far as to express this to others in the department and have a private
    conversation with the head of the department (my boss's boss),
    expressing my disappointment with redhat support to him.
    My experience has been good and I have no negative feelings about their
    support offering. We had a critical issue once on a production server
    with 250 users, and that they solved for us very quickly. Other lower
    priority issues have been resolved in appropriate time frames.
    From my perspective, its all good.
    Ian
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/x-pkcs7-signature
    Size: 3630 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20091020/dfcc5362/attachment.bin
  • Keith Keller at Oct 19, 2009 at 10:29 pm

    On Tue, Oct 20, 2009 at 08:29:59AM +1030, Ian Blackwell wrote:
    My experience has been good and I have no negative feelings about their
    support offering. We had a critical issue once on a production server
    with 250 users, and that they solved for us very quickly. Other lower
    priority issues have been resolved in appropriate time frames.
    I am curious, for those who have used RH support, what sorts of issues
    they have (or have not) resolved. Are these relatively simple issues,
    or do you (and they) end up digging into the guts of the kernel?

    --keith

    --
    kkeller at speakeasy.net

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 197 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20091019/2d920147/attachment.bin
  • Ken at Oct 19, 2009 at 11:16 pm
    War is a failure of the imagination.
    --William Blake


    On 10/19/2009 06:29 PM Keith Keller wrote:
    On Tue, Oct 20, 2009 at 08:29:59AM +1030, Ian Blackwell wrote:
    My experience has been good and I have no negative feelings about their
    support offering. We had a critical issue once on a production server
    with 250 users, and that they solved for us very quickly. Other lower
    priority issues have been resolved in appropriate time frames.
    I am curious, for those who have used RH support, what sorts of issues
    they have (or have not) resolved. Are these relatively simple issues,
    or do you (and they) end up digging into the guts of the kernel?

    --keith
    Okay, here's one. Maybe someone here can figure it out.

    Upgrading from 4.5 to 4.5. From a 4.6 ISO I copied all the RPMs into a
    directory... let's call it c:/install :). Now the oracle dba has
    strict parameters on what versions can be installed and which can't.
    The rpms in c:/install meet those requirements. In addition, since this
    is a production machine, it can be down at most for one day. So all I
    want to do is upgrade what's currently on the system. Moreover, if
    something horks, I want two chances to back out (the second being asking
    the backup guy to put the system back to yesterday). The command to do
    this would be

    rpm --freshen --repackage *

    run in that crazy c:/install directory (or what the redhat guy called, a
    "folder"). This command runs fine for one file which has no
    dependencies (i.e., change '*' to a specific rpm). It also upgrades
    three or four co-dependent rpms if they're narrowly specified. But if
    the file/rpm spec is '*', rpm complains about two missing dependencies
    and stops.

    Yeah, this directory contains 1507 rpms (IIRC)... which is a lot, but it
    should still work. This is Linux, after all. And there's plenty enough
    memory and cpu to handle it.

    [The rh support written response was that there wasn't a problem, that
    this was "expected behavior". When I phoned the guy and gently pressed
    him on that statement, he backed off of it a little, said, "yeah, it
    should work" but "no one does it that way" and I "really shouldn't
    expect it to work."]

    I had a couple other issues with the same command, but I'm not in the
    office now and don't recall them. Yep, my brain's in time-off mode.

    But anyone have any experience or background, enough to say why that rpm
    command above is failing so miserably... and then what might fix it?

    If so, big thanks.
  • Benjamin Franz at Oct 20, 2009 at 4:15 pm

    ken wrote:
    Okay, here's one. Maybe someone here can figure it out.
    Upgrading from 4.5 to 4.5. From a 4.6 ISO I copied all the RPMs into a
    directory... let's call it c:/install :). Now the oracle dba has
    strict parameters on what versions can be installed and which can't.
    The rpms in c:/install meet those requirements. In addition, since this
    is a production machine, it can be down at most for one day. So all I
    want to do is upgrade what's currently on the system. Moreover, if
    something horks, I want two chances to back out (the second being asking
    the backup guy to put the system back to yesterday). The command to do
    this would be

    rpm --freshen --repackage *

    run in that crazy c:/install directory (or what the redhat guy called, a
    "folder"). This command runs fine for one file which has no
    dependencies (i.e., change '*' to a specific rpm). It also upgrades
    three or four co-dependent rpms if they're narrowly specified. But if
    the file/rpm spec is '*', rpm complains about two missing dependencies
    and stops.

    Yeah, this directory contains 1507 rpms (IIRC)... which is a lot, but it
    should still work. This is Linux, after all. And there's plenty enough
    memory and cpu to handle it.
    Running

    rpm --freshen --repackage *

    for 1500+ rpms probably exceeds the maximum character length for some
    part of the system after expansion of the '*' by the shell.

    Try breaking it up into smaller chunks (say two or three hundred at a
    time). You can match subsets of the files using shell expansions like

    rpm --freshen --repackage [a-g]*

    and tweak the line for any dependency complaints manually.

    Alternatively, use 'createrepo' to create a Yum repository of the RPMs
    and use yum to handle it for you.

    --
    Benjamin Franz







    [The rh support written response was that there wasn't a problem, that
    this was "expected behavior". When I phoned the guy and gently pressed
    him on that statement, he backed off of it a little, said, "yeah, it
    should work" but "no one does it that way" and I "really shouldn't
    expect it to work."]

    I had a couple other issues with the same command, but I'm not in the
    office now and don't recall them. Yep, my brain's in time-off mode.

    But anyone have any experience or background, enough to say why that rpm
    command above is failing so miserably... and then what might fix it?

    If so, big thanks.

    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos

    --
    Benjamin Franz
  • Ken at Oct 21, 2009 at 9:12 am

    On 10/20/2009 12:15 PM Benjamin Franz wrote:
    ken wrote:
    Okay, here's one. Maybe someone here can figure it out.
    Upgrading from 4.5 to 4.5. From a 4.6 ISO I copied all the RPMs into a
    directory... let's call it c:/install :). Now the oracle dba has
    strict parameters on what versions can be installed and which can't.
    The rpms in c:/install meet those requirements. In addition, since this
    is a production machine, it can be down at most for one day. So all I
    want to do is upgrade what's currently on the system. Moreover, if
    something horks, I want two chances to back out (the second being asking
    the backup guy to put the system back to yesterday). The command to do
    this would be

    rpm --freshen --repackage *

    run in that crazy c:/install directory (or what the redhat guy called, a
    "folder"). This command runs fine for one file which has no
    dependencies (i.e., change '*' to a specific rpm). It also upgrades
    three or four co-dependent rpms if they're narrowly specified. But if
    the file/rpm spec is '*', rpm complains about two missing dependencies
    and stops.

    Yeah, this directory contains 1507 rpms (IIRC)... which is a lot, but it
    should still work. This is Linux, after all. And there's plenty enough
    memory and cpu to handle it.
    Running

    rpm --freshen --repackage *

    for 1500+ rpms probably exceeds the maximum character length for some
    part of the system after expansion of the '*' by the shell.
    That was my first suspicion too. The redhat tech didn't bring that up
    though. (That doesn't mean I'm going to ignore that as a possible
    workaround; the original conversation here was about tech support per
    se. Of course I'm still seeking ways to do the job. And so thanks for
    the suggestion.)

    I, too, recall reading some years back about a bash line length limit.
    Back then, a long time ago, it was 2048 characters. So I ran "echo *"
    in that same install/ directory and the output included all 1507 files.
    So the problem's not with a bash command line length limit, but still
    pointing to the "rpm" command.


    Try breaking it up into smaller chunks (say two or three hundred at a
    time). You can match subsets of the files using shell expansions like

    rpm --freshen --repackage [a-g]*

    and tweak the line for any dependency complaints manually.
    This solution occurred to me also. And right now it's a top contender
    (along with another I'll mention shortly). If the job environment were
    different, I'd go with it. But my boss is making me jump through a lot
    of hoops for this project. This upgrade from v.4.5 to v.4.6 needs to
    happen in a single, specified day *and* my boss needs to know how long
    it will take me to accomplish, this so the Oracle dba knows when he can
    start to on what he's got to do for this upgrade. And I have at most
    fifteen hours (i.e., two working days) to come up with this fool-proof
    plan. Plus, I don't have a test box to try things out on. But I've had
    to do trickier stuff than this in the past with not dissimilar time
    constraints, so though I should be taking extra boxers to work, I'm not
    (yet).

    So what I was thinking of doing is scripting the solution you suggest
    above. But then, if I'm going to script something, I might as well
    write a script that will take on the entire task wholistically. I mean
    something like this:

    ls -1 install/ > what-to-upgrade.list # create package list
    while read package | {upgrade package} #just quasi-code here. Loop.
    if {there's nothing to upgrade}
    remove pkg from what-to-upgrade.list
    log this
    continue
    fi
    if {there are dependencies}
    then for {each dependency} {upgrade package} # yep, recursion
    fi
    else [upgrade package} # simplest case, just upgrade one pkg

    The {upgrade package} function would be fairly simple (I think):
    - Find the correct package in the install/ directory (containing the
    RPMs for v.4.6).
    - Upgrade the 4.5 package with that correct 4.6 package.
    - Confirm that the 4.6 is installed.
    - Remove that package name from what-to-upgrade.list
    - Log that this package has been upgraded.

    I already see some bogus stuff here, but I'm writing this on the fly.
    Point is, it seems do-able, and probably within the time constraints.
    And then, what are the alternatives?

    One, suggested by the redhat tech (about whom there's more news...
    later), is to use up2date. I read the manpage on it and it's pretty
    vague. I'm sure I have, but I don't recall using it before, so I can't
    fill in the details which the manpage lacks. Lastly, I don't see a way
    to test up2date to see if it will work within my (dba's) specific
    parameters.


    Benjamin, thanks for your constructive response. Any further such (from
    you or anyone else) will be much appreciated.

    Best,
    ken
    Alternatively, use 'createrepo' to create a Yum repository of the RPMs
    and use yum to handle it for you.
  • David Fix at Oct 21, 2009 at 11:31 am
    Sorry, don't have time to read the whole thread (busy day!), so please excuse me if I just add to the noise, but this may work for you (at a bash prompt):


    for x in *; do rpm --freshen --repackage $x; done


    If it's not what you're looking for, I apologize in advance. :)


    --
    David Fix


    ----- Original Message -----
    From: "ken" <gebser at mousecar.com>
    To: "CentOS mailing list" <centos at centos.org>
    Sent: Wednesday, October 21, 2009 5:12:14 AM
    Subject: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a CentOS)

    On 10/20/2009 12:15 PM Benjamin Franz wrote:
    ken wrote:
    Okay, here's one. Maybe someone here can figure it out.
    Upgrading from 4.5 to 4.5. From a 4.6 ISO I copied all the RPMs into a
    directory... let's call it c:/install :). Now the oracle dba has
    strict parameters on what versions can be installed and which can't.
    The rpms in c:/install meet those requirements. In addition, since this
    is a production machine, it can be down at most for one day. So all I
    want to do is upgrade what's currently on the system. Moreover, if
    something horks, I want two chances to back out (the second being asking
    the backup guy to put the system back to yesterday). The command to do
    this would be

    rpm --freshen --repackage *

    run in that crazy c:/install directory (or what the redhat guy called, a
    "folder"). This command runs fine for one file which has no
    dependencies (i.e., change '*' to a specific rpm). It also upgrades
    three or four co-dependent rpms if they're narrowly specified. But if
    the file/rpm spec is '*', rpm complains about two missing dependencies
    and stops.

    Yeah, this directory contains 1507 rpms (IIRC)... which is a lot, but it
    should still work. This is Linux, after all. And there's plenty enough
    memory and cpu to handle it.
    Running

    rpm --freshen --repackage *

    for 1500+ rpms probably exceeds the maximum character length for some
    part of the system after expansion of the '*' by the shell.
    That was my first suspicion too. The redhat tech didn't bring that up
    though. (That doesn't mean I'm going to ignore that as a possible
    workaround; the original conversation here was about tech support per
    se. Of course I'm still seeking ways to do the job. And so thanks for
    the suggestion.)

    I, too, recall reading some years back about a bash line length limit.
    Back then, a long time ago, it was 2048 characters. So I ran "echo *"
    in that same install/ directory and the output included all 1507 files.
    So the problem's not with a bash command line length limit, but still
    pointing to the "rpm" command.


    Try breaking it up into smaller chunks (say two or three hundred at a
    time). You can match subsets of the files using shell expansions like

    rpm --freshen --repackage [a-g]*

    and tweak the line for any dependency complaints manually.
    This solution occurred to me also. And right now it's a top contender
    (along with another I'll mention shortly). If the job environment were
    different, I'd go with it. But my boss is making me jump through a lot
    of hoops for this project. This upgrade from v.4.5 to v.4.6 needs to
    happen in a single, specified day *and* my boss needs to know how long
    it will take me to accomplish, this so the Oracle dba knows when he can
    start to on what he's got to do for this upgrade. And I have at most
    fifteen hours (i.e., two working days) to come up with this fool-proof
    plan. Plus, I don't have a test box to try things out on. But I've had
    to do trickier stuff than this in the past with not dissimilar time
    constraints, so though I should be taking extra boxers to work, I'm not
    (yet).

    So what I was thinking of doing is scripting the solution you suggest
    above. But then, if I'm going to script something, I might as well
    write a script that will take on the entire task wholistically. I mean
    something like this:

    ls -1 install/ > what-to-upgrade.list # create package list
    while read package | {upgrade package} #just quasi-code here. Loop.
    if {there's nothing to upgrade}
    remove pkg from what-to-upgrade.list
    log this
    continue
    fi
    if {there are dependencies}
    then for {each dependency} {upgrade package} # yep, recursion
    fi
    else [upgrade package} # simplest case, just upgrade one pkg

    The {upgrade package} function would be fairly simple (I think):
    - Find the correct package in the install/ directory (containing the
    RPMs for v.4.6).
    - Upgrade the 4.5 package with that correct 4.6 package.
    - Confirm that the 4.6 is installed.
    - Remove that package name from what-to-upgrade.list
    - Log that this package has been upgraded.

    I already see some bogus stuff here, but I'm writing this on the fly.
    Point is, it seems do-able, and probably within the time constraints.
    And then, what are the alternatives?

    One, suggested by the redhat tech (about whom there's more news...
    later), is to use up2date. I read the manpage on it and it's pretty
    vague. I'm sure I have, but I don't recall using it before, so I can't
    fill in the details which the manpage lacks. Lastly, I don't see a way
    to test up2date to see if it will work within my (dba's) specific
    parameters.


    Benjamin, thanks for your constructive response. Any further such (from
    you or anyone else) will be much appreciated.

    Best,
    ken
    Alternatively, use 'createrepo' to create a Yum repository of the RPMs
    and use yum to handle it for you.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20091021/91fb0c34/attachment.html
  • KFisler at Oct 21, 2009 at 11:53 am
    The problem with such a loop is that only one pkg is the arg to each
    invocation of the rpm command. So if there are any dependencies for a
    particular invocation, nothing will be installed.



    From:
    David Fix <davidf at mrxfx.com>
    To:
    CentOS mailing list <centos at centos.org>
    Date:
    10/21/2009 07:32 AM
    Subject:
    Re: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a
    CentOS)
    Sent by:
    centos-bounces at centos.org



    Sorry, don't have time to read the whole thread (busy day!), so please
    excuse me if I just add to the noise, but this may work for you (at a bash
    prompt):

    for x in *; do rpm --freshen --repackage $x; done

    If it's not what you're looking for, I apologize in advance. :)

    --
    David Fix


    ----- Original Message -----
    From: "ken" <gebser at mousecar.com>
    To: "CentOS mailing list" <centos at centos.org>
    Sent: Wednesday, October 21, 2009 5:12:14 AM
    Subject: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat
    and a CentOS)

    On 10/20/2009 12:15 PM Benjamin Franz wrote:
    ken wrote:
    Okay, here's one. Maybe someone here can figure it out.
    Upgrading from 4.5 to 4.5. From a 4.6 ISO I copied all the RPMs into a
    directory... let's call it c:/install :). Now the oracle dba has
    strict parameters on what versions can be installed and which can't.
    The rpms in c:/install meet those requirements. In addition, since
    this
    is a production machine, it can be down at most for one day. So all I
    want to do is upgrade what's currently on the system. Moreover, if
    something horks, I want two chances to back out (the second being
    asking
    the backup guy to put the system back to yesterday). The command to do
    this would be

    rpm --freshen --repackage *

    run in that crazy c:/install directory (or what the redhat guy called,
    a
    "folder"). This command runs fine for one file which has no
    dependencies (i.e., change '*' to a specific rpm). It also upgrades
    three or four co-dependent rpms if they're narrowly specified. But if
    the file/rpm spec is '*', rpm complains about two missing dependencies
    and stops.

    Yeah, this directory contains 1507 rpms (IIRC)... which is a lot, but
    it
    should still work. This is Linux, after all. And there's plenty
    enough
    memory and cpu to handle it.
    Running

    rpm --freshen --repackage *

    for 1500+ rpms probably exceeds the maximum character length for some
    part of the system after expansion of the '*' by the shell.
    That was my first suspicion too. The redhat tech didn't bring that up
    though. (That doesn't mean I'm going to ignore that as a possible
    workaround; the original conversation here was about tech support per
    se. Of course I'm still seeking ways to do the job. And so thanks for
    the suggestion.)

    I, too, recall reading some years back about a bash line length limit.
    Back then, a long time ago, it was 2048 characters. So I ran "echo *"
    in that same install/ directory and the output included all 1507 files.
    So the problem's not with a bash command line length limit, but still
    pointing to the "rpm" command.


    Try breaking it up into smaller chunks (say two or three hundred at a
    time). You can match subsets of the files using shell expansions like

    rpm --freshen --repackage [a-g]*

    and tweak the line for any dependency complaints manually.
    This solution occurred to me also. And right now it's a top contender
    (along with another I'll mention shortly). If the job environment were
    different, I'd go with it. But my boss is making me jump through a lot
    of hoops for this project. This upgrade from v.4.5 to v.4.6 needs to
    happen in a single, specified day *and* my boss needs to know how long
    it will take me to accomplish, this so the Oracle dba knows when he can
    start to on what he's got to do for this upgrade. And I have at most
    fifteen hours (i.e., two working days) to come up with this fool-proof
    plan. Plus, I don't have a test box to try things out on. But I've had
    to do trickier stuff than this in the past with not dissimilar time
    constraints, so though I should be taking extra boxers to work, I'm not
    (yet).

    So what I was thinking of doing is scripting the solution you suggest
    above. But then, if I'm going to script something, I might as well
    write a script that will take on the entire task wholistically. I mean
    something like this:

    ls -1 install/ > what-to-upgrade.list # create package list
    while read package | {upgrade package} #just quasi-code here. Loop.
    if {there's nothing to upgrade}
    remove pkg from what-to-upgrade.list
    log this
    continue
    fi
    if {there are dependencies}
    then for {each dependency} {upgrade package} # yep, recursion
    fi
    else [upgrade package} # simplest case, just upgrade one pkg

    The {upgrade package} function would be fairly simple (I think):
    - Find the correct package in the install/ directory (containing the
    RPMs for v.4.6).
    - Upgrade the 4.5 package with that correct 4.6 package.
    - Confirm that the 4.6 is installed.
    - Remove that package name from what-to-upgrade.list
    - Log that this package has been upgraded.

    I already see some bogus stuff here, but I'm writing this on the fly.
    Point is, it seems do-able, and probably within the time constraints.
    And then, what are the alternatives?

    One, suggested by the redhat tech (about whom there's more news...
    later), is to use up2date. I read the manpage on it and it's pretty
    vague. I'm sure I have, but I don't recall using it before, so I can't
    fill in the details which the manpage lacks. Lastly, I don't see a way
    to test up2date to see if it will work within my (dba's) specific
    parameters.


    Benjamin, thanks for your constructive response. Any further such (from
    you or anyone else) will be much appreciated.

    Best,
    ken
    Alternatively, use 'createrepo' to create a Yum repository of the RPMs
    and use yum to handle it for you.
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20091021/2b6d18db/attachment.html
  • David Fix at Oct 21, 2009 at 2:11 pm
    Gotcha. :) Sorry about that. :)

    --
    David Fix


    ----- Original Message -----
    From: KFisler at lakelandcc.edu
    To: "CentOS mailing list" <centos at centos.org>
    Sent: Wednesday, October 21, 2009 7:53:31 AM
    Subject: Re: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a CentOS)

    The problem with such a loop is that only one pkg is the arg to each invocation of the rpm command. So if there are any dependencies for a particular invocation, nothing will be installed.


    From: David Fix <davidf at mrxfx.com>
    To: CentOS mailing list <centos at centos.org>
    Date: 10/21/2009 07:32 AM
    Subject: Re: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a CentOS)
    Sent by: centos-bounces at centos.org




    Sorry, don't have time to read the whole thread (busy day!), so please excuse me if I just add to the noise, but this may work for you (at a bash prompt):

    for x in *; do rpm --freshen --repackage $x; done

    If it's not what you're looking for, I apologize in advance. :)

    --
    David Fix


    ----- Original Message -----
    From: "ken" <gebser at mousecar.com>
    To: "CentOS mailing list" <centos at centos.org>
    Sent: Wednesday, October 21, 2009 5:12:14 AM
    Subject: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a CentOS)

    On 10/20/2009 12:15 PM Benjamin Franz wrote:
    ken wrote:
    Okay, here's one. Maybe someone here can figure it out.
    Upgrading from 4.5 to 4.5. From a 4.6 ISO I copied all the RPMs into a
    directory... let's call it c:/install :). Now the oracle dba has
    strict parameters on what versions can be installed and which can't.
    The rpms in c:/install meet those requirements. In addition, since this
    is a production machine, it can be down at most for one day. So all I
    want to do is upgrade what's currently on the system. Moreover, if
    something horks, I want two chances to back out (the second being asking
    the backup guy to put the system back to yesterday). The command to do
    this would be

    rpm --freshen --repackage *

    run in that crazy c:/install directory (or what the redhat guy called, a
    "folder"). This command runs fine for one file which has no
    dependencies (i.e., change '*' to a specific rpm). It also upgrades
    three or four co-dependent rpms if they're narrowly specified. But if
    the file/rpm spec is '*', rpm complains about two missing dependencies
    and stops.

    Yeah, this directory contains 1507 rpms (IIRC)... which is a lot, but it
    should still work. This is Linux, after all. And there's plenty enough
    memory and cpu to handle it.
    Running

    rpm --freshen --repackage *

    for 1500+ rpms probably exceeds the maximum character length for some
    part of the system after expansion of the '*' by the shell.
    That was my first suspicion too. The redhat tech didn't bring that up
    though. (That doesn't mean I'm going to ignore that as a possible
    workaround; the original conversation here was about tech support per
    se. Of course I'm still seeking ways to do the job. And so thanks for
    the suggestion.)

    I, too, recall reading some years back about a bash line length limit.
    Back then, a long time ago, it was 2048 characters. So I ran "echo *"
    in that same install/ directory and the output included all 1507 files.
    So the problem's not with a bash command line length limit, but still
    pointing to the "rpm" command.


    Try breaking it up into smaller chunks (say two or three hundred at a
    time). You can match subsets of the files using shell expansions like

    rpm --freshen --repackage [a-g]*

    and tweak the line for any dependency complaints manually.
    This solution occurred to me also. And right now it's a top contender
    (along with another I'll mention shortly). If the job environment were
    different, I'd go with it. But my boss is making me jump through a lot
    of hoops for this project. This upgrade from v.4.5 to v.4.6 needs to
    happen in a single, specified day *and* my boss needs to know how long
    it will take me to accomplish, this so the Oracle dba knows when he can
    start to on what he's got to do for this upgrade. And I have at most
    fifteen hours (i.e., two working days) to come up with this fool-proof
    plan. Plus, I don't have a test box to try things out on. But I've had
    to do trickier stuff than this in the past with not dissimilar time
    constraints, so though I should be taking extra boxers to work, I'm not
    (yet).

    So what I was thinking of doing is scripting the solution you suggest
    above. But then, if I'm going to script something, I might as well
    write a script that will take on the entire task wholistically. I mean
    something like this:

    ls -1 install/ > what-to-upgrade.list # create package list
    while read package | {upgrade package} #just quasi-code here. Loop.
    if {there's nothing to upgrade}
    remove pkg from what-to-upgrade.list
    log this
    continue
    fi
    if {there are dependencies}
    then for {each dependency} {upgrade package} # yep, recursion
    fi
    else [upgrade package} # simplest case, just upgrade one pkg

    The {upgrade package} function would be fairly simple (I think):
    - Find the correct package in the install/ directory (containing the
    RPMs for v.4.6).
    - Upgrade the 4.5 package with that correct 4.6 package.
    - Confirm that the 4.6 is installed.
    - Remove that package name from what-to-upgrade.list
    - Log that this package has been upgraded.

    I already see some bogus stuff here, but I'm writing this on the fly.
    Point is, it seems do-able, and probably within the time constraints.
    And then, what are the alternatives?

    One, suggested by the redhat tech (about whom there's more news...
    later), is to use up2date. I read the manpage on it and it's pretty
    vague. I'm sure I have, but I don't recall using it before, so I can't
    fill in the details which the manpage lacks. Lastly, I don't see a way
    to test up2date to see if it will work within my (dba's) specific
    parameters.


    Benjamin, thanks for your constructive response. Any further such (from
    you or anyone else) will be much appreciated.

    Best,
    ken
    Alternatively, use 'createrepo' to create a Yum repository of the RPMs
    and use yum to handle it for you.
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos


    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20091021/8cf47613/attachment.html
  • Barry Brimer at Oct 21, 2009 at 2:03 pm
    On Wed, 21 Oct 2009, ken wrote:
    On 10/20/2009 12:15 PM Benjamin Franz wrote:
    ken wrote:
    Okay, here's one. Maybe someone here can figure it out.
    Upgrading from 4.5 to 4.5. From a 4.6 ISO I copied all the RPMs into a
    directory... let's call it c:/install :). Now the oracle dba has
    strict parameters on what versions can be installed and which can't.
    The rpms in c:/install meet those requirements. In addition, since this
    is a production machine, it can be down at most for one day. So all I
    want to do is upgrade what's currently on the system. Moreover, if
    something horks, I want two chances to back out (the second being asking
    the backup guy to put the system back to yesterday). The command to do
    this would be

    rpm --freshen --repackage *

    run in that crazy c:/install directory (or what the redhat guy called, a
    "folder"). This command runs fine for one file which has no
    dependencies (i.e., change '*' to a specific rpm). It also upgrades
    three or four co-dependent rpms if they're narrowly specified. But if
    the file/rpm spec is '*', rpm complains about two missing dependencies
    and stops.

    Yeah, this directory contains 1507 rpms (IIRC)... which is a lot, but it
    should still work. This is Linux, after all. And there's plenty enough
    memory and cpu to handle it.
    Running

    rpm --freshen --repackage *

    for 1500+ rpms probably exceeds the maximum character length for some
    part of the system after expansion of the '*' by the shell.
    That was my first suspicion too. The redhat tech didn't bring that up
    though. (That doesn't mean I'm going to ignore that as a possible
    workaround; the original conversation here was about tech support per
    se. Of course I'm still seeking ways to do the job. And so thanks for
    the suggestion.)

    I, too, recall reading some years back about a bash line length limit.
    Back then, a long time ago, it was 2048 characters. So I ran "echo *"
    in that same install/ directory and the output included all 1507 files.
    So the problem's not with a bash command line length limit, but still
    pointing to the "rpm" command.


    Try breaking it up into smaller chunks (say two or three hundred at a
    time). You can match subsets of the files using shell expansions like

    rpm --freshen --repackage [a-g]*

    and tweak the line for any dependency complaints manually.
    This solution occurred to me also. And right now it's a top contender
    (along with another I'll mention shortly). If the job environment were
    different, I'd go with it. But my boss is making me jump through a lot
    of hoops for this project. This upgrade from v.4.5 to v.4.6 needs to
    happen in a single, specified day *and* my boss needs to know how long
    it will take me to accomplish, this so the Oracle dba knows when he can
    start to on what he's got to do for this upgrade. And I have at most
    fifteen hours (i.e., two working days) to come up with this fool-proof
    plan. Plus, I don't have a test box to try things out on. But I've had
    to do trickier stuff than this in the past with not dissimilar time
    constraints, so though I should be taking extra boxers to work, I'm not
    (yet).

    So what I was thinking of doing is scripting the solution you suggest
    above. But then, if I'm going to script something, I might as well
    write a script that will take on the entire task wholistically. I mean
    something like this:

    ls -1 install/ > what-to-upgrade.list # create package list
    while read package | {upgrade package} #just quasi-code here. Loop.
    if {there's nothing to upgrade}
    remove pkg from what-to-upgrade.list
    log this
    continue
    fi
    if {there are dependencies}
    then for {each dependency} {upgrade package} # yep, recursion
    fi
    else [upgrade package} # simplest case, just upgrade one pkg

    The {upgrade package} function would be fairly simple (I think):
    - Find the correct package in the install/ directory (containing the
    RPMs for v.4.6).
    - Upgrade the 4.5 package with that correct 4.6 package.
    - Confirm that the 4.6 is installed.
    - Remove that package name from what-to-upgrade.list
    - Log that this package has been upgraded.

    I already see some bogus stuff here, but I'm writing this on the fly.
    Point is, it seems do-able, and probably within the time constraints.
    And then, what are the alternatives?

    One, suggested by the redhat tech (about whom there's more news...
    later), is to use up2date. I read the manpage on it and it's pretty
    vague. I'm sure I have, but I don't recall using it before, so I can't
    fill in the details which the manpage lacks. Lastly, I don't see a way
    to test up2date to see if it will work within my (dba's) specific
    parameters.
    If you add --aid on the end of your rpm command, and you are in the
    directory with the rpms, it should solve any dependency issues for you
    provided that the rpms that are needed are in the local directory. If a
    pendency is resolved by something that you later try to upgrade i *think*
    rpm will just tell you that that particular package is already installed.
    I could be wrong. Either way .. try the --aid. Also, don't forget that
    you can add the --test flag to rpm to find out if rpm will work or not.

    Hope this helps,
    Barry
  • Ken at Oct 21, 2009 at 11:18 pm

    On 10/21/2009 10:03 AM Barry Brimer wrote:
    On Wed, 21 Oct 2009, ken wrote:
    On 10/20/2009 12:15 PM Benjamin Franz wrote:
    ken wrote:
    Okay, here's one. Maybe someone here can figure it out.
    Upgrading from 4.5 to 4.5. From a 4.6 ISO I copied all the RPMs into a
    directory... let's call it c:/install :). Now the oracle dba has
    strict parameters on what versions can be installed and which can't.
    The rpms in c:/install meet those requirements. In addition, since this
    is a production machine, it can be down at most for one day. So all I
    want to do is upgrade what's currently on the system. Moreover, if
    something horks, I want two chances to back out (the second being asking
    the backup guy to put the system back to yesterday). The command to do
    this would be

    rpm --freshen --repackage *

    run in that crazy c:/install directory (or what the redhat guy called, a
    "folder"). This command runs fine for one file which has no
    dependencies (i.e., change '*' to a specific rpm). It also upgrades
    three or four co-dependent rpms if they're narrowly specified. But if
    the file/rpm spec is '*', rpm complains about two missing dependencies
    and stops.

    Yeah, this directory contains 1507 rpms (IIRC)... which is a lot, but it
    should still work. This is Linux, after all. And there's plenty enough
    memory and cpu to handle it.
    Running

    rpm --freshen --repackage *

    for 1500+ rpms probably exceeds the maximum character length for some
    part of the system after expansion of the '*' by the shell.
    That was my first suspicion too. The redhat tech didn't bring that up
    though. (That doesn't mean I'm going to ignore that as a possible
    workaround; the original conversation here was about tech support per
    se. Of course I'm still seeking ways to do the job. And so thanks for
    the suggestion.)

    I, too, recall reading some years back about a bash line length limit.
    Back then, a long time ago, it was 2048 characters. So I ran "echo *"
    in that same install/ directory and the output included all 1507 files.
    So the problem's not with a bash command line length limit, but still
    pointing to the "rpm" command.


    Try breaking it up into smaller chunks (say two or three hundred at a
    time). You can match subsets of the files using shell expansions like

    rpm --freshen --repackage [a-g]*

    and tweak the line for any dependency complaints manually.
    This solution occurred to me also. And right now it's a top contender
    (along with another I'll mention shortly). If the job environment were
    different, I'd go with it. But my boss is making me jump through a lot
    of hoops for this project. This upgrade from v.4.5 to v.4.6 needs to
    happen in a single, specified day *and* my boss needs to know how long
    it will take me to accomplish, this so the Oracle dba knows when he can
    start to on what he's got to do for this upgrade. And I have at most
    fifteen hours (i.e., two working days) to come up with this fool-proof
    plan. Plus, I don't have a test box to try things out on. But I've had
    to do trickier stuff than this in the past with not dissimilar time
    constraints, so though I should be taking extra boxers to work, I'm not
    (yet).

    So what I was thinking of doing is scripting the solution you suggest
    above. But then, if I'm going to script something, I might as well
    write a script that will take on the entire task wholistically. I mean
    something like this:

    ls -1 install/ > what-to-upgrade.list # create package list
    while read package | {upgrade package} #just quasi-code here. Loop.
    if {there's nothing to upgrade}
    remove pkg from what-to-upgrade.list
    log this
    continue
    fi
    if {there are dependencies}
    then for {each dependency} {upgrade package} # yep, recursion
    fi
    else [upgrade package} # simplest case, just upgrade one pkg

    The {upgrade package} function would be fairly simple (I think):
    - Find the correct package in the install/ directory (containing the
    RPMs for v.4.6).
    - Upgrade the 4.5 package with that correct 4.6 package.
    - Confirm that the 4.6 is installed.
    - Remove that package name from what-to-upgrade.list
    - Log that this package has been upgraded.

    I already see some bogus stuff here, but I'm writing this on the fly.
    Point is, it seems do-able, and probably within the time constraints.
    And then, what are the alternatives?

    One, suggested by the redhat tech (about whom there's more news...
    later), is to use up2date. I read the manpage on it and it's pretty
    vague. I'm sure I have, but I don't recall using it before, so I can't
    fill in the details which the manpage lacks. Lastly, I don't see a way
    to test up2date to see if it will work within my (dba's) specific
    parameters.
    If you add --aid on the end of your rpm command, and you are in the
    directory with the rpms, it should solve any dependency issues for you
    provided that the rpms that are needed are in the local directory. If a
    pendency is resolved by something that you later try to upgrade i *think*
    rpm will just tell you that that particular package is already installed.
    I could be wrong. Either way .. try the --aid. Also, don't forget that
    you can add the --test flag to rpm to find out if rpm will work or not.

    Hope this helps,
    Barry
    Barry,

    In fact I tried that at work today (at the suggestion of a redhat tech),
    but no go. I don't understand why. According to the docs, it should...
    but it simply didn't. But you are correct about the --test option.
    It's worked fine for days (at least :). Good thing too, as I don't have
    a development box to do any testing on.

    Thanks for the reply though. People on this list are really great folk.

    Best,
    ken
  • Todd Denniston at Oct 21, 2009 at 2:27 pm

    ken wrote, On 10/21/2009 05:12 AM:
    On 10/20/2009 12:15 PM Benjamin Franz wrote:
    ken wrote:
    <SNIP>
    Yeah, this directory contains 1507 rpms (IIRC)... which is a lot, but it
    should still work. This is Linux, after all. And there's plenty enough
    memory and cpu to handle it.
    Running

    rpm --freshen --repackage *

    for 1500+ rpms probably exceeds the maximum character length for some
    part of the system after expansion of the '*' by the shell.
    <SNIP understanding shell command length>

    <SNIP drawn out scripting>
    Benjamin, thanks for your constructive response. Any further such (from
    you or anyone else) will be much appreciated.

    Best,
    ken
    Alternatively, use 'createrepo' to create a Yum repository of the RPMs
    and use yum to handle it for you.
    Ken,
    please let me second the idea for using createrepo on the collection so that you can then use yum to
    resolve everything.

    Assuming "/install" is where the rpms are at and createrepo is installed from base(at least on 5. it
    is in base), running the following commands should get the system going:

    createrepo /install
    cat >> /etc/yum.repos.d/quickupdate.repo << END_EOF
    [expedient]
    name=expedient update dir
    baseurl=file:///install
    enabled=0
    #assume the machine already has gpg key for all rpms you have
    gpgcheck=1
    END_EOF
    yum update --disablerepo=\* --enablerepo=expedient



    alternatively if the problem is not really the shell length, then
    yum localupdate /install
    or
    yum localupdate /install/*
    might work.
    https://www.centos.org/modules/news/article.php?storyid8#comment90
    http://fedoraforum.org/forum/archive/index.php/t-140404.html

    --
    Todd Denniston
    Crane Division, Naval Surface Warfare Center (NSWC Crane)
    Harnessing the Power of Technology for the Warfighter
  • Ken at Oct 22, 2009 at 12:21 am
    War is a failure of the imagination.
    --William Blake


    On 10/21/2009 10:27 AM Todd Denniston wrote:
    ken wrote, On 10/21/2009 05:12 AM:
    On 10/20/2009 12:15 PM Benjamin Franz wrote:
    ken wrote:
    <SNIP>
    Yeah, this directory contains 1507 rpms (IIRC)... which is a lot, but it
    should still work. This is Linux, after all. And there's plenty enough
    memory and cpu to handle it.
    Running

    rpm --freshen --repackage *

    for 1500+ rpms probably exceeds the maximum character length for some
    part of the system after expansion of the '*' by the shell.
    <SNIP understanding shell command length>

    <SNIP drawn out scripting>
    Benjamin, thanks for your constructive response. Any further such (from
    you or anyone else) will be much appreciated.

    Best,
    ken
    Alternatively, use 'createrepo' to create a Yum repository of the RPMs
    and use yum to handle it for you.
    Ken,
    please let me second the idea for using createrepo on the collection so that you can then use yum to
    resolve everything.

    Assuming "/install" is where the rpms are at and createrepo is installed from base(at least on 5. it
    is in base), running the following commands should get the system going:

    createrepo /install
    cat >> /etc/yum.repos.d/quickupdate.repo << END_EOF
    [expedient]
    name=expedient update dir
    baseurl=file:///install
    enabled=0
    #assume the machine already has gpg key for all rpms you have
    gpgcheck=1
    END_EOF
    yum update --disablerepo=\* --enablerepo=expedient



    alternatively if the problem is not really the shell length, then
    yum localupdate /install
    or
    yum localupdate /install/*
    might work.
    https://www.centos.org/modules/news/article.php?storyid8#comment90
    http://fedoraforum.org/forum/archive/index.php/t-140404.html
    Todd, I like your idea and love all the details you provide. I use yum
    at home (on the machine I'm hitting on now and one other one) and love
    it. One of the first things I did when I got handed this rh v.4.5
    machine was to check for yum. It's not there. I looked around redhat's
    site for a version of it to run on 4.5, but couldn't find it. It did
    exist for 4.5, but for some reason my predecessor didn't install it.

    I'll hunt around for it some more, but if anyone knows a place on the
    web, a link would be great. Until then, it looks like I might have to
    use up2date. For some reason I don't feel a lot of joy in that prospect.

    Thanks for the great yum info.

Related Discussions

People

Translate

site design / logo © 2022 Grokbase