I used to update centos via yum update command...
When i first installed VMPRo i saw that in the sysinfopage appeared some virtualmin related updates.. Since then i have made the updates whenever they appear...
But what about the other updates via yum... If i do a yum check-update i can see there are many available updates... but i see one about the virtualmin base... virtualmin-base.noarch 1.0-57.rh virtualmin
Do i have to make all the updates manually?
This is the complete list
[root@ ~]# yum check-update Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files
MySQL-python.x86_64 1.2.2-1 virtualmin
cups.x86_64 1:1.2.4-11.14.el5_1.6 updates
cups-libs.x86_64 1:1.2.4-11.14.el5_1.6 updates
device-mapper-multipath.x86_64 0.4.7-12.el5_1.3 updates
kpartx.x86_64 0.4.7-12.el5_1.3 updates
krb5-libs.i386 1.6.1-17.el5_1.1 updates
krb5-libs.x86_64 1.6.1-17.el5_1.1 updates
krb5-workstation.x86_64 1.6.1-17.el5_1.1 updates
php-mcrypt.x86_64 5.1.6-15.el5.centos.1 extras
sos.noarch 1.7-9.2.el5 updates
squid.x86_64 7:2.6.STABLE6-5.el5_1. updates
virtualmin-base.noarch 1.0-57.rh virtualmin<br><br>Post edited by: RicardoOrduna, at: 2008/04/30 14:42
Hi Ricardo,
The yum update list at the homepage of Virtualmin Pro only lists Virtualmin packages.
You will STILL NEED TO DO MANUAL YUM-UPDATE to update other packages (not taken care of by Virtualmin Pro) used on your server.
If you do manual yum-update, all the Virtualmin Pro packages will also be updated as well. So you only need to do manual yum-update.
You probably already know this: it is advisable to do yum-update on a development/test server BEFORE you do it on the production server to avoid any nasty surprises.<br><br>Post edited by: ah...lifes...good, at: 2008/05/02 14:52
Yes i understand...
But i still have a question... What about the virtualmin-base.noarch 1.0-57.rh package listed on the yum check-update???
Does it have some dependence with the Virtualmin Pro i'm currently using? Is there a probem if update it? Will it mess with my VirtualminPro setup?
Thanks
It's harmless to upgrade it, but it also won't do much of anything. It only actually does most of its work on first installation--it contains the configuration script that sets everything up to work smoothly with Virtualmin.
We sometimes sneak in little bits of updates, and we also use it to add new dependencies to the system, but that's kind of changing over time, as Virtualmin and Webmin get better at auto-handling dependencies (for example, we used to use it for adding new php or perl modules that were needed for Install Scripts, but now Install Scripts can generally automatically add them when they are needed).
--
Check out the forum guidelines!
Actually I rely on webmin to keep my system up-to-date and secure.
(although I do things manually as well)
For instance PHP isn't updated by Centos, so I would have to do this manually on a production server.
Im not too happy about it and would rely on webmin to do this for me.
This is my opinion and based on the fact that I am not the greatest Linux Operator alive.
"How many folks thought Virtualmin Package Updates was all the updating you ever needed to do on your system?"
Me! That is why i bought it.
"Me! That is why i bought it."
What we have here is a failure to communicate. ;-)
We always want to do what is best for users--even if it means we catch more blame for problems. And, actually, this makes the code a wee bit simpler (right now we've got code that tries to figure out whether it is a Virtualmin related package or not). But, I think we need to figure out a way to make the updates seem more like a helpful reminder about "system" updates rather than "here's some more packages that those dudse at Virtualmin want you to install right away, and last time I did that my system wouldn't boot!"
So, ah might be on the right track with the separation between OS and Virtualmin in the updates list. That's kinda complexicated, though, and I fear we might confuse folks. This might be a job for usability testing...
--
Check out the forum guidelines!
Hey guys, it just hit me...there's a nice solution to this problem staring me right in the face. We just tell people who provides the package--this would also solve a lot of package conflict complaints caused by folks having incompatible package sources configured and not realizing the update that the updates module offered them was not from Virtualmin. If they saw that it came from FreshRPMs or Dag or whatever, they'd know that it's not a package we're recommending--it just happens to be newer than what they currently have installed (and hopefully, if they're savvy enough to add alternate repositories they're savvy enough to know that not all packages are compatible with each other and can be upgraded smoothly across versions--some of them are, but not all).
We can easily know who provides all of the updates on yum, so all we have to do is include that information in the output. So, we add another "Provided by" field--which will say "CentOS 5.1 - i386" or "Virtualmin Universal" or "Virtualmin CentOS 5.1 i386", etc. This is much easier information to get on yum-based systems than Debian/Ubuntu, unfortunately...but I'm betting there's a way we can find it from apt-get as well.
--
Check out the forum guidelines!
"How many folks thought Virtualmin Package Updates was all the updating you ever needed to do on your system?"
From a customer's/user's point of view, I would wish to have Virtualmin automatically update *everything* and send me a report every morning starting with "Sir yes Sir...", brew my coffee, feed my dog (hang on I don't have a dog, OK feed my neighbour's dog), file my fingernails, pay my bills etc. ;-)
Yes, seriously, it would be great if Virtualmin could do what Red Hat is doing: one-click-and-update-everything.
But, realistically, I don't think it is humanly possible for Jamie and Joe to provide flawless support for MULTIPLE operating systems *at the moment* (unless they get serious VC funding and have more employees).
If Virtualmin Inc. is well-funded and have many clicky geniuses like Jamie and Joe, then perhaps we could look at different versions of Virtualmin Pro that provides seamless server management and operations:
Virtualmin Pro (CentOS edition)
Virtualmin Pro (Fedora edition)
Virtualmin Pro (...)
Virtualmin Pro (...)
At that point, Virtualmin Pro could be packaged and licensed with hardwares (i.e. servers), and Joe and Jamie will be zillionaires, after being bought out by Sun Microsystems (who are infamous for buying out competitors and great products, and killing them eventually) ;-)
* I don't know how many people here still remember the Cobalt RaQ servers. That business model will work very well with Virtualmin Inc.
---------------------------------------------------------------
In reply to your latest post, yes, attributing the packages to their "owners" will help.
But if I were you, I will still include a very prominent warning about possible incompatibility issues etc.
I can only speak from my point of view.
When I started out earlier this year, I was looking for a "webhosting and system management software"
cPanel was out as was Plesk and I didn't like directadmin and others.
Webmin however appealed to me right away and I switched to CentOS as it was recommended (where I tried ubuntu and debian before).
So I thought webmin would take care of the system (considering the fact that I am new to linux all together).
My thoughts were based on reading documentation and understanding it the way I did at that time.
I now understand better that it isn't easy if not impossible to do. Also I didn't know at that time that webmin has a 2 persons staff, not that it matters to me.
Pointing back to my earlier post concerning php version 5.1.6
I would really like to upgrade to the latest version but centos does not supply that, ergo I can't upgrade as I don't know how and I don't want to experiment on a production server.
Also I don't want to use repositories from people I don't know or are not supported/endorced by CentOS and Webmin..
It's true, I am not knowledgeable enough to advice in this matter
<div class='quote'>It's true, I am not knowledgeable enough to advice in this matter </div>
No, you're exactly the person we want to hear from on the issue. We are just two guys, and we are overworked, but we also see a very clear path to profitability (and hiring a few additional people) as long as we're making our users exquisitely happy. If having package updates deal with all packages makes you happier with your Virtualmin box, we'll make that happen.
I will mention that for the first three or four months of Virtualmin Professional's existence, we setup automatic updates on all of our supported systems--every night the package manager ran and updated everything available. We caught the most furious flack we've ever received for this "feature". It really pissed off a lot of people (and we didn't even have that many users yet). Thus, we've been trying to tread carefully in this area ever since...people take their packages and upgrades seriously (and to a degree that is rational--sometimes upgrades do break things in mysterious ways, and the long-running, so long-running that years later I'm still not sure if it's actually fixed, mkinitrd issue in CentOS and RHEL in versions 4 and 5 that leads to a failure to boot after a kernel upgrade is certainly not helping matters).
As for PHP, I actually have plans to implement a "cutting edge" optional repository for our most popular platforms (probably just CentOS 5 and Debian 4) that always has the latest PHP, SpamAssassin, and maybe one or two other packages. This has been out of reach, so far, as I just don't have the time--there are three major projects on my plate right now and a half dozen minor ones. But it's in the plans--give it a few weeks, and solutions will be in place for folks to run the cutting edge versions of stuff (we won't necessarily recommend them...but they will be available if you <i>needp</i> something in a really new version.
--
Check out the forum guidelines!
I guess in my view there is a difference in upgrading the OS and upgrading software needed for webhosting.
Kernel and other related stuff should be handled by (in my case) CentOS.
PHP, mysql, spamassassin and packages like this needed for daily webhosting can be updated through webmin.
It is may be not a strict correct view but it is how I perceive it. I think many users with limited knowledge of GNU/Linux would see it this way.
Like your regular windoze user, no one cares about the OS, it should just run and you should be able to trust it is correct.
But most care about the application one uses on a daily basis.
Alright, so the next version (not the one that just went out this morning, I don't think, but 2.9) will provide access to all updates, and will include information about where the package is coming from. Jamie's a champ.
I suspect Virtualmin Package Updates will also find its way into Webmin in the future as a core module, as it now provides a much nicer way to deal with packages than System Packages...of course, it'll need to tie into the System Packages module in some way, since we don't want to confuse people with multiple ways to do things.
--
Check out the forum guidelines!
Yes, ah is right. It's a problematic thing, as the Virtualmin Package Updates module is focused on just the packages that we depend on and use (though two of the ones in your list ought to be included--php-mcrypt and MySQL-python, and I'll see about getting that fixed).
I dunno if it's the right way to go. There's already a Webmin module for doing a system-wide update--the System:System Packages module supports yum and apt-get...so, the Virtualmin Package Updates module was focused on just hosting related packages.
One of the problems we've noticed with package updates (even now, and this would get much worse if it listed all packages) is that folks think we're responsible for everything that appears on the front page--so when a system package update breaks something, <i>we</i> hear about it, even though there's nothing we can do about the problem--a broken package provided by the OS vendor is not something we can fix, generally, so it's sort of a misdirection of efforts. But, then again, some folks are lulled into thinking we are willing to be responsible for the whole OS, and so they expect package updates to list everything.
Maybe it would be best if we did list everything...I think it's a hard call, and I don't have enough data to know.
Maybe a poll would help:
How many folks thought Virtualmin Package Updates was all the updating you ever needed to do on your system?
--
Check out the forum guidelines!
<div class='quote'>One of the problems we've noticed with package updates (even now, and this would get much worse if it listed all packages) is that folks think we're responsible for everything that appears on the front page</div>
Hi Joe,
1. Putting on my thinking hat as a business manager (i.e. looking from Virtualmin Inc.'s point of view), I don't think that Virtualmin Pro should ever have a function to do a wholesale yum-update.
Reason: If you do, and something goes wrong (e.g. kernel upgrade causes server crash), you could potentially be sued for damages - consequential loss of income.
Your current policy is a good policy, from a business point of view.
2. My suggestion on how VMpro can add further value:
Where you currently show available package updates at the frontpage of Virtualmin Pro... have 2 columns.
Column 1 - Clearly states "VMpro-related packages" + the UPDATE Button
Column 2 - "Packages not related to VMpro (for info purpose only)" + link to virtualmin.com's page for more info on how to yum-update and warning of potential dangers (e.g. possible server crash on kernel update etc.).