I noticed that install.sh is somewhat lengthy and has a bunch of hard-coded package names and other specific OS stuff.
It seems to me that you would be better off in the long run to simplify install.sh to just have the bulk of the script reside in your repository.
That is, install.sh should probably just download the real install script (passing a customer specific identifier and current os id to virtualmin.com) and execute that.
That way, the script that is downloaded could be specific to the OS and if you had to make changes to it (to fix or add something) it would be fixed for all customers running the script.
I'd also recommend the script install a command called "vmp" that would be like rpm or yum but operates on a Virtualmin Pro installation to do things like "vmp install", "vmp update", "vmp list", "vmp delete" which would control the installation. The Virtualmin GUI could have a System Update interface to this command.
I'd kind of like to do "vmp update" instead of up2date or yum to pick up any changes to keep my server completely up to date. That is, I'd like to turn over the upgrading of any installed packages to Virtualmin Pro (even if Virtualmin Pro in fact turns to the Red Hat repository for the updates).
Forget the "vmp" idea. I've been looking into things more and yum seems to be the solution for keeping the server up to date.
My suggestion to have a much simpler install.sh stands though.
Hey Kevin,
We actually have developed a Virtualmin package installer for Webmin, and it works well. It will be used to support those platforms that do not have reasonable package management built in (Solaris, possibly some of the BSDs, Slackware), but as you've noted yum is the Right Way on systems that can support it. There's no way we could match the power and flexibility of yum+rpm. It's an amazingly good tool that addresses every major problem of software installation and update management. I simply adore yum.
I agree with simplifying the install.sh. It has already begun, the next version pulls several things out into a couple of library files that get downloaded during installation. Logging is the first to go, and all of the simple functions I use will be next. By the end of it all, install.sh will just be a downloader and all else will happen in pulled down scripts and packages. I had hoped to put almost everything into the virtualmin-base package, but unfortunately, the package management on even our currently supported platforms was so ornery that it became impossible to do it that way--Fedora/CentOS could do it because they have yum and SUSE 10.0 could do it because yast works right on that version, but RHEL and SUSE 9.3 fell over and refused to cooperate--neither one could handle using our repos correctly to resolve deps (for different reasons: RHEL because up2date doesn't fully support yum repos and yum can't use Red Hat repos for dep resolution; SUSE because yast in 9.3 is broken by design and too stupid to resolve deps even when given all of the packages in a single source). So every other platform ended up with the ugliness that the install.sh script now is. It was really beautiful and clean and short when I had only Fedora working. ]:-|
In short, I know it's a bit ugly, but it got that way because it has to work...The pretty one only worked for a third of our supported platforms.
--
Check out the forum guidelines!
Well, I don't mind "ugly" code. I'm a developer too so I know how it goes sometimes.
I still would prefer if the install.sh I upload to the server I want to manage with Virtualmin be as short as possible so that I would never have to worry about whether it is still the current one I should be using if I need to reinstall.
Why not just have install.sh use curl or wget to fetch the current install.sh and then execute the fetched file with the users license key?
I also suggest that you echo the output from install.sh to a /var/log/virtualmin.log file. That way, there would be a record of how the install went if there was ever any question as to whether it was a clean install or what the install actually did.
Hey Kevin,
You're right on all counts--though most of the install already happens in the virtualmin-base package (which is downloaded fresh when you start the install), and so it is already rather close to your ideal...it just doesn't look it. It also changes very infrequently...there have been about four versions posted in the six months that its been in use, while we're up to 27 on the virtualmin-base RPM.
Nonetheless, I agree that it needs to do less and be more resilient to change. The download/copy step of the install is one of the more annoying aspects of the installation, and so I want to minimize it. Actually, I believe we'll be removing it altogether in another few days--I'm planning to begin offering a cut/paste command line that can download the installer and run it. So, all you'll have to do to install will be to copy a line like:
wget -O - http://serial:key@software.virtualmin.com/install.cgi | /bin/sh
Or something along those lines. It'll always generate the latest install.sh and run it.
As for logging, the next release pulls in log4sh and does a lot of extra logging to /root/virtualmin-install.log. Before we call this thing stable, it will also have the ability to email me if a problem occurs so that we'll better be able to resolve install issues. It'll also lead to less stdout spewage during install--but one can review the log to find out all of the stuff that now just scrolls by. Version EA2 will include all of these changes. Hopefully, this weekend.
--
Check out the forum guidelines!