What is the relationship between OpenSuse and SLED - Suse

This is a discussion on What is the relationship between OpenSuse and SLED - Suse ; GŁnther Schwarz wrote: > In my case it was still running from the previous try 24h back. The > updater has to give up at some point instead of eating up ressources in > an infinite loop as in 10.2. ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 26 of 26

Thread: What is the relationship between OpenSuse and SLED

  1. Re: Comparing update systems

    GŁnther Schwarz wrote:
    > In my case it was still running from the previous try 24h back. The
    > updater has to give up at some point instead of eating up ressources in
    > an infinite loop as in 10.2. The problem was fixed with 10.3 obviously.


    OK, I am talking about current software e.g. openSUSE 11.0

    > This would be too many mails here. There are several things initiated by
    > crond including updates of rrd databases which are done every 5
    > minutes. I do not want all of this mail :-)


    If you don't want the mails (forwarded or elsewere) why would you send
    them in the first place? What do you do with the mails now?

    >> The reason this is done is it might leave your system unworkable,
    >> because you will need to reboot. Not an option for a server when that
    >> happens on a saturday evening and everybody is out.

    >
    > But it should be left to my decision and responsibility. That said up to
    > now I never had a system in an inoperative state after a kernel update,
    > so knock on wood. But then I do not do automatic updates on the machine
    > that offers the vital services like LDAP and mail.


    OK, so you do it manualy. Then for those machines you won't be using
    cron-apt. There is no reason to run cron-apt if you don't want to do the
    update in the first place.

    >> The thing I run with is:
    >> zypper --quiet up -y -t patch --skip-interactive
    >>
    >> That way it won't install anything that asks for a license or a
    >> reboot.

    >
    > And I will never get new kernel versions or Acrobat Reader without
    > having a close look at the updates and what was skipped.


    Not sure about acrobate reader with the update. The kernel indeed not. I
    am confused as to what you want exactly. You run cron-tab at certain
    times (say at night) and then what happens?

    > Yes, it uses the apt-get command which then calls the dpkg package
    > handler.


    I looked a bit at the source and it is basicaly just a script that runs
    apt-get if I am not mistaken. Just like you can make a script that does
    about the same for zypper with very little effort.

    >> Make one script that does that for you. Indeed it is expected that you
    >> just use that you need. With what you are running, I am sure you know
    >> how to put together a bash script that is able to do this for you.

    >
    > Yes, of course. I did this for smart and it works just fine. But a
    > script that parses the zypper output correctly will be lengthy and
    > cumbersome to write up for the reason I mentioned previously.


    No, it won't. I might not be as easy as one would like, but it is very
    doable. Depending on what you want, you can easily do it in a few lines.
    The sample output of the latest I recieved:
    From: root@penne.houghi
    To: root@penne.houghi
    Subject: Cron zypper --quiet up -y -t patch
    --skip-interactive
    From root@penne.houghi Mon Jun 30 04:43:45 2008

    The following packages are going to be upgraded:
    php5-iconv php5-pdo php5-dom php5-hash apache2-mod_php5
    php5-xmlwriter php5-mysql php5-json php5-ctype
    php5-xmlreader php5 php5-tokenizer php5-sqlite

    The following NEW patch is going to be installed:
    apache2-mod_php5
    ^[[2K^MContinue? [YES/no]: yes

    Yes, the last line is ugly and all the filenames are in one line. Filter
    out the Coninue line and you are about done if that is so upsetting for
    you. All in all I am pretty happy with the information.

    >> From what I see both have about the same functionality. The big
    >> difference is that cron-apt is already there, while for openSUSE you
    >> would need to write your own few lines of code if you need to change
    >> the servers often.

    >
    > This is what I am complaining about. Zypper obviously is not intended
    > for use other than a simple and isolated desktop system. Otherwise the
    > developers would have thought about how to make it managable and usable
    > in a networked environment. No one has time to write scripts for simple
    > desktop systems these days.


    In what way is cron-apt intended for anything else, because from what I
    have seen, all it does is run apt-get on the machine it is installed.
    http://packages.debian.org/sid/cron-apt
    Contains a tool that is run by a cron job at regular intervals. By
    default it just updates the package list and download new packages
    without installing. You can instruct it to run anything that you can do
    with apt-get (or aptitude).

    I have seen nothing that makes it any better in what is already
    possible.

    And I write scripts for simple desktops all the time. The moment I use
    two or three commands after another, I put it in a script.

    > Leaving the bugs aside the main difference here is that the person who
    > wrote the cron-apt package had networked environments in mind and
    > thought about a way to do things in a convenient way on these.


    I am sorry, I fail to see where is does anything that would relate to a
    networked enviroment.

    > At SuSE
    > people were thinking of isolated desktop systems (zypper) or
    > heterogenous environments (rug) obviously. One results in a focus on
    > tray bar icons and a colorful interface while the other becomes
    > interesting only in big networks running Novell's server software.


    That part about the GUI is bull and you know it. We were talking about
    zypper and CLI all the time. Yes, the GUI is an importand part for
    openSUSE, because that is what many people now want. It however has
    nothing to do with what we are talking about.

    > Another point is that cron-apt and apt-get are set up in the traditional
    > UNIX way were everything is configured via ASCII text files. The SuSE
    > tools are more 'modern' and abstract from the OS with configuration in
    > databases. This can result in better performance and give the
    > possibility to write platform-independent tools.


    So this is good, right?

    > Rug is even a .NET application that runs in a mono environment and is
    > obviously intended as a replacement for the Microsoft updater on
    > Windows clients.


    No idea. I do not know anything about Microsoft. The automatic updater
    has been a part of the distro since forever. What they have done is put
    YOU and Redcarpet together and out came rug/zypper/libzypp
    So no, it was not intended as a replacement for the windows updater.

    > As a result both are much less flexible and harder to handle for a
    > sysadmin who is used to work the old UNIX way.


    That is the fault of the sysadmin, not of the tool.

    > Editing files is much simpler and safer than using scripts which call
    > complex commands like zypper or rug.


    Why would it be safer? Simpler? No. I think it is pretty simple to just
    either do the setup in YaST for the updates or put the lines in cron
    myself or if need be make a small script that does the different steps.

    But again I ask what cron-apt does that is specificaly pointed towards
    networked computing.

    houghi
    --
    They say pesticides have been linked to low sperm counts.
    In my opinion if you have bugs down there that are so bad
    you need to use a pesticide, you're not gonna get laid anyway.

  2. Re: Comparing update systems

    houghi wrote:

    > GŁnther Schwarz wrote:


    >>> The reason this is done is it might leave your system unworkable,
    >>> because you will need to reboot. Not an option for a server when
    >>> that happens on a saturday evening and everybody is out.

    >>
    >> But it should be left to my decision and responsibility. That said up
    >> to now I never had a system in an inoperative state after a kernel
    >> update, so knock on wood. But then I do not do automatic updates on
    >> the machine that offers the vital services like LDAP and mail.

    >
    > OK, so you do it manualy. Then for those machines you won't be using
    > cron-apt.


    It can be configured no to do kernel updates automatically. But the
    system is question is not a Debian one, so this does not apply anyways.

    >>> The thing I run with is:
    >>> zypper --quiet up -y -t patch --skip-interactive
    >>>
    >>> That way it won't install anything that asks for a license or a
    >>> reboot.

    >>
    >> And I will never get new kernel versions or Acrobat Reader without
    >> having a close look at the updates and what was skipped.

    >
    > Not sure about acrobate reader with the update. The kernel indeed not.
    > I am confused as to what you want exactly. You run cron-tab at certain
    > times (say at night) and then what happens?


    It checks for updates at the repositories, downloads and installs them.
    There is no magic involved. It just works nicer than the tools I have
    at hand with SuSE.

    >> Yes, it uses the apt-get command which then calls the dpkg package
    >> handler.

    >
    > I looked a bit at the source and it is basicaly just a script that
    > runs apt-get if I am not mistaken. Just like you can make a script
    > that does about the same for zypper with very little effort.


    Well, the difference is that cron-apt is available in the first place.
    So I do not have any work to do myself other than a little
    configuration.

    >>> Make one script that does that for you. Indeed it is expected that
    >>> you just use that you need. With what you are running, I am sure you
    >>> know how to put together a bash script that is able to do this for
    >>> you.

    >>
    >> Yes, of course. I did this for smart and it works just fine. But a
    >> script that parses the zypper output correctly will be lengthy and
    >> cumbersome to write up for the reason I mentioned previously.

    >
    > No, it won't. I might not be as easy as one would like, but it is very
    > doable. Depending on what you want, you can easily do it in a few
    > lines. The sample output of the latest I recieved:
    > From: root@penne.houghi
    > To: root@penne.houghi
    > Subject: Cron zypper --quiet up -y -t patch
    > --skip-interactive
    > From root@penne.houghi Mon Jun 30 04:43:45 2008
    >
    > The following packages are going to be upgraded:
    > php5-iconv php5-pdo php5-dom php5-hash apache2-mod_php5
    > php5-xmlwriter php5-mysql php5-json php5-ctype
    > php5-xmlreader php5 php5-tokenizer php5-sqlite
    >
    > The following NEW patch is going to be installed:
    > apache2-mod_php5
    > ^[[2K^MContinue? [YES/no]: yes
    >
    > Yes, the last line is ugly and all the filenames are in one line.
    > Filter out the Coninue line and you are about done if that is so
    > upsetting for you. All in all I am pretty happy with the information.


    It would be nice this way. But your example is with 11.0 obviously. The
    10.3 systems here won't be retired until 2009, and I have to find a
    solution for this. Otherwise they do run nicely, so I have no intention
    to go to kernel 2.6.25 anytime soon. It is either parsing the nasty
    output to a readable form or switching to smart like I already did with
    10.2 where zypper has proven to be plain horror. I would like to stay
    with the default updater, so I'm working now on the parsing problem.

    >> This is what I am complaining about. Zypper obviously is not intended
    >> for use other than a simple and isolated desktop system. Otherwise
    >> the developers would have thought about how to make it managable and
    >> usable in a networked environment. No one has time to write scripts
    >> for simple desktop systems these days.

    >
    > In what way is cron-apt intended for anything else, because from what
    > I have seen, all it does is run apt-get on the machine it is
    > installed. http://packages.debian.org/sid/cron-apt
    > Contains a tool that is run by a cron job at regular intervals. By
    > default it just updates the package list and download new packages
    > without installing. You can instruct it to run anything that you can
    > do with apt-get (or aptitude).
    >
    > I have seen nothing that makes it any better in what is already
    > possible.


    As I said there is nothing special about it: it simply works without
    annoying bugs and is easy to configure. That makes it superior to a
    tool that is still buggy and harder to work with. But I'm repeating
    myself here.

    >> Leaving the bugs aside the main difference here is that the person
    >> who wrote the cron-apt package had networked environments in mind and
    >> thought about a way to do things in a convenient way on these.

    >
    > I am sorry, I fail to see where is does anything that would relate to
    > a networked enviroment.


    Think of a small system with several servers and PCs which share big
    parts of their configuration. Maintenance work has to be restricted to
    the absolute minimum possible without compromising security and
    availability. Automatic updates are vital for such a system as is a
    configuration tool like cfengine.

    >> At SuSE
    >> people were thinking of isolated desktop systems (zypper) or
    >> heterogenous environments (rug) obviously. One results in a focus on
    >> tray bar icons and a colorful interface while the other becomes
    >> interesting only in big networks running Novell's server software.

    >
    > That part about the GUI is bull and you know it.


    No, it is not ;-) The default installation results in a GUI updater that
    pops up a window if updates are available while the CLI tool for
    automatic updates is buggy (which might have been fixed in the most
    recent release).

    > We were talking about
    > zypper and CLI all the time. Yes, the GUI is an importand part for
    > openSUSE, because that is what many people now want. It however has
    > nothing to do with what we are talking about.


    It has, as time spent on making a system user-friendly for the isolated
    desktop easily results in time missing for development and testing of
    tools and procedures to do remote administration. This is basically
    what I'm complaining about.

    >> Another point is that cron-apt and apt-get are set up in the
    >> traditional UNIX way were everything is configured via ASCII text
    >> files. The SuSE tools are more 'modern' and abstract from the OS with
    >> configuration in databases. This can result in better performance and
    >> give the possibility to write platform-independent tools.

    >
    > So this is good, right?


    This is interesting if a company wants to write software for mixed
    environments. But it is also challenging and might result in more
    complex software with questionable benefits.

    >> Rug is even a .NET application that runs in a mono environment and is
    >> obviously intended as a replacement for the Microsoft updater on
    >> Windows clients.

    >
    > No idea. I do not know anything about Microsoft. The automatic updater
    > has been a part of the distro since forever. What they have done is
    > put YOU and Redcarpet together and out came rug/zypper/libzypp
    > So no, it was not intended as a replacement for the windows updater.


    This applies to rug only. See


    (Well, this is not about rug exactly, but about the full Zenworks Patch
    Management which is supposed to work with about any OS known to mankind
    and where rug is one part of.)

    >> As a result both are much less flexible and harder to handle for a
    >> sysadmin who is used to work the old UNIX way.

    >
    > That is the fault of the sysadmin, not of the tool.
    >
    >> Editing files is much simpler and safer than using scripts which call
    >> complex commands like zypper or rug.

    >
    > Why would it be safer? Simpler? No.


    Oh yes, it is. Show me a complete list of possible outputs of these two
    commands. This does not exist. It is a try and error procedure to get a
    working script that does automatic updates with these commands and
    informs the sysadmin what has been done in a comprehensive an reliable
    way.

    GŁnther

  3. Re: Comparing update systems

    GŁnther Schwarz wrote:
    >> Not sure about acrobate reader with the update. The kernel indeed not.
    >> I am confused as to what you want exactly. You run cron-tab at certain
    >> times (say at night) and then what happens?

    >
    > It checks for updates at the repositories, downloads and installs them.
    > There is no magic involved. It just works nicer than the tools I have
    > at hand with SuSE.


    1) it is openSUSE or if you run SLE it is SUSE.
    2) I am completely baffeld with the fact that the two things do the same
    in the background and still you [prefere one over the other

    >> I looked a bit at the source and it is basicaly just a script that
    >> runs apt-get if I am not mistaken. Just like you can make a script
    >> that does about the same for zypper with very little effort.

    >
    > Well, the difference is that cron-apt is available in the first place.
    > So I do not have any work to do myself other than a little
    > configuration.


    From what you seem to want to be doing, configuring the updates via YaST
    should be all that you need.

    > It would be nice this way. But your example is with 11.0 obviously. The
    > 10.3 systems here won't be retired until 2009, and I have to find a
    > solution for this. Otherwise they do run nicely, so I have no intention
    > to go to kernel 2.6.25 anytime soon. It is either parsing the nasty
    > output to a readable form or switching to smart like I already did with
    > 10.2 where zypper has proven to be plain horror. I would like to stay
    > with the default updater, so I'm working now on the parsing problem.


    I agree with you on the output. Perhaps if somebody files a bugreport,
    they repair it. It might be worth a try.

    > As I said there is nothing special about it: it simply works without
    > annoying bugs and is easy to configure. That makes it superior to a
    > tool that is still buggy and harder to work with. But I'm repeating
    > myself here.


    Apart from the email that looks like ****, I do not see where the tool
    is buggy. So we must have a different opinion there. I use the automated
    updates since 5.4 or so and I have never seen anything that I would call
    'buggy'.

    >> I am sorry, I fail to see where is does anything that would relate to
    >> a networked enviroment.

    >
    > Think of a small system with several servers and PCs which share big
    > parts of their configuration. Maintenance work has to be restricted to
    > the absolute minimum possible without compromising security and
    > availability. Automatic updates are vital for such a system as is a
    > configuration tool like cfengine.


    I understand what a network is. I fail to see what extra cron-apt brings
    to the table that does things specificaly for a network enviroment.

    How would you do this in a openSUSE network enviroment (non SLE, but
    openSUSE)? 1) Have one machine fetch the updates for all the versions of
    openSUSE, SUSE and SuSE and even S.u.S.E. you are running. (Might need
    to make some updates yourself for certain systems)
    2) Have each machine do the automatic update (either with YOU or with
    sypper) point to your server.
    3) Done

    You might think that part 2 is very difficult, but it isn't. If there
    are not to many machines, you can do it during instalation. Takes about
    30 seconds.

    If there are many machines you might need to write a small script that
    you need to run once from each machine (wget server/script.sh && sh
    script sh) for already installed machines.

    If you need to install many machines, you install once, configure it,
    save that configuration and open it with each instalation. This will
    give you similar systems even on non-similar hardware.

    If you need to install a ****lead amount of machines, you make your own
    instalation disk where you have in the beginning e.g. a selection
    between student, teacher, server, portable and on each machine you just
    click once on your selection and go to the next.

    There are many options possible depending on the amount that are already
    installed, amount of types and who is doing the instalation and how
    different you want them to be.

    >> That part about the GUI is bull and you know it.

    >
    > No, it is not ;-) The default installation results in a GUI updater that
    > pops up a window if updates are available while the CLI tool for
    > automatic updates is buggy (which might have been fixed in the most
    > recent release).


    I have never seen that. Also I know that they do some work on it, but
    you make it sound as if that is all they care about and that is theb
    bull part.

    > It has, as time spent on making a system user-friendly for the isolated
    > desktop easily results in time missing for development and testing of
    > tools and procedures to do remote administration. This is basically
    > what I'm complaining about.


    And again I ask you what the cron-apt tool does specificaly network
    related, meaning a network of computers. It must be there as you keep
    saying, so I must be overlooking it.

    >> So this is good, right?

    >
    > This is interesting if a company wants to write software for mixed
    > environments. But it is also challenging and might result in more
    > complex software with questionable benefits.


    Almost all networks are in a mixed enviroment. Be it Windows, Mac or
    other Linux distributions or versions. There are not very much non-mixed
    enviroments.

    >>> Editing files is much simpler and safer than using scripts which call
    >>> complex commands like zypper or rug.

    >>
    >> Why would it be safer? Simpler? No.

    >
    > Oh yes, it is. Show me a complete list of possible outputs of these two
    > commands. This does not exist. It is a try and error procedure to get a
    > working script that does automatic updates with these commands and
    > informs the sysadmin what has been done in a comprehensive an reliable
    > way.


    Uh sorry? Trial and error? I just put it in YaST and that is it. No
    trial, no error, no scripting. It just works. The fact that you and me
    are talking about underlying stuff does not mean that automated updating
    is not very easy.

    You can make it more complicated if you want and there might be specific
    cases where that might be, but it is not needed.

    houghi
    --
    It's people. Source code is made out of people! They're making our
    source out of people. Next thing they'll be breeding us like cattle
    for code. You've gotta tell them. You've gotta tell them!

  4. Re: Comparing update systems

    houghi wrote:

    > GŁnther Schwarz wrote:


    >> It checks for updates at the repositories, downloads and installs
    >> them. There is no magic involved. It just works nicer than the tools
    >> I have at hand with SuSE.


    > 2) I am completely baffeld with the fact that the two things do the
    > same in the background and still you [prefere one over the other


    I did not write the things in the background. That would be a discussion
    about rpm vs. deb package management. I'm fine with both basically.

    >>> I looked a bit at the source and it is basicaly just a script that
    >>> runs apt-get if I am not mistaken. Just like you can make a script
    >>> that does about the same for zypper with very little effort.

    >>
    >> Well, the difference is that cron-apt is available in the first
    >> place. So I do not have any work to do myself other than a little
    >> configuration.

    >
    > From what you seem to want to be doing, configuring the updates via
    > YaST should be all that you need.


    Configuring automatic updates via YAST does nothing but placing
    a 'zypper up (-y)' in /etc/cron.d/. I tried to explain that I want to
    keep track about updates by collecting reports in an IMAP folder. That
    is the method of choice for me as I do not have a more sophisticated
    management tools like Zenworks or WSUS at hand. Cron-apt does exactly
    that, the SuSE tools do not without additional scripting.

    >> It would be nice this way. But your example is with 11.0 obviously.
    >> The 10.3 systems here won't be retired until 2009, and I have to find
    >> a solution for this. Otherwise they do run nicely, so I have no
    >> intention to go to kernel 2.6.25 anytime soon. It is either parsing
    >> the nasty output to a readable form or switching to smart like I
    >> already did with 10.2 where zypper has proven to be plain horror. I
    >> would like to stay with the default updater, so I'm working now on
    >> the parsing problem.

    >
    > I agree with you on the output. Perhaps if somebody files a bugreport,
    > they repair it. It might be worth a try.


    I nearly finished now a script that uses the --terse option for zypper.
    But I will have to run it for a while in order to see what it does on
    different events like the occasional kernel updates.

    >>> I am sorry, I fail to see where is does anything that would relate
    >>> to a networked enviroment.

    >>
    >> Think of a small system with several servers and PCs which share big
    >> parts of their configuration. Maintenance work has to be restricted
    >> to the absolute minimum possible without compromising security and
    >> availability. Automatic updates are vital for such a system as is a
    >> configuration tool like cfengine.

    >
    > I understand what a network is. I fail to see what extra cron-apt
    > brings to the table that does things specificaly for a network
    > enviroment.


    See above. It enables me to keep track of things with minimum effort. If
    I want to revise the update history of a specific machine I can look it
    up quickly in my mail instead of logging in and checking in /var.

    > How would you do this in a openSUSE network enviroment (non SLE, but
    > openSUSE)? 1) Have one machine fetch the updates for all the versions
    > of openSUSE, SUSE and SuSE and even S.u.S.E. you are running. (Might
    > need to make some updates yourself for certain systems)


    That is not needed as I do have a local mirror which is maintained by
    the IT staff. I can also configure all systems to get their updates
    from download.opensuse.org or wherever as bandwith is not an issue. As
    for the enterprise versions: these are bound to one specific update
    server anyway due to the license model.

    GŁnther

  5. Re: Comparing update systems

    GŁnther Schwarz wrote:
    >> 2) I am completely baffeld with the fact that the two things do the
    >> same in the background and still you [prefere one over the other

    >
    > I did not write the things in the background.


    I know that, that is why I did not say that you did. What I said was
    that you run (e.g. let cron handle the start of) those programs in the
    background.

    > That would be a discussion about rpm vs. deb package management. I'm
    > fine with both basically.


    No idea where you suddenly came up with any comparison between rpm and
    deb.

    >> From what you seem to want to be doing, configuring the updates via
    >> YaST should be all that you need.

    >
    > Configuring automatic updates via YAST does nothing but placing
    > a 'zypper up (-y)' in /etc/cron.d/. I tried to explain that I want to
    > keep track about updates by collecting reports in an IMAP folder. That
    > is the method of choice for me as I do not have a more sophisticated
    > management tools like Zenworks or WSUS at hand. Cron-apt does exactly
    > that, the SuSE tools do not without additional scripting.


    So it is the fact that zypper doesn't place the file in an IMAP but
    sends a mail is the problem?

    > See above. It enables me to keep track of things with minimum effort. If
    > I want to revise the update history of a specific machine I can look it
    > up quickly in my mail instead of logging in and checking in /var.


    OK, could you place the info you get from cron-apt here, so it becomes
    clear?


    houghi
    --



    This space left blank intentionaly

  6. Re: What is the relationship between OpenSuse and SLED

    G?nther Schwarz wrote:
    > Because no one offering a distribution free of charge will have the
    > manpower and ressources to backport every single patch to outdated
    > program and kernel versions for such a long time. This is a service for
    > customers who are willing to pay for it.


    Look at Slackware, basically a "one-person maintained" distribution.
    Current version is 12.1, but Pat is still maintaining versions back
    to 8.1 (which was released in June 2002), the latest patches for THAT
    came out in July:
    Mon Jul 28 22:05:06 CDT 2008
    patches/packages/fetchmail-6.3.8-i486-1_slack8.1.tgz:
    Patched to fix a possible denial of service when "-v -v" options are
    used.
    For more information, see:
    http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-2711
    (* Security fix *)

    And this IS a completely free-of-charge distribution (OK, you _can_
    buy the CD's and/or DVD and have them sent to you, but even that is
    within the affordable range (about $50,- for the CD set, $60 for the
    DVD). Both the CD's as well as the DVD are also downloadable cq can
    be gotten via BitTorrent P2P.

    So some people ARE willing to support older versions a long time!
    --
    ************************************************** *****************
    ** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
    ** e-mail: E.J.M.Hartman@tudelft.nl, fax: +31-15-278 7295 **
    ** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
    ************************************************** *****************

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2