Oh man, i dont even know where to start but lets begin:
- Installer failing on Centos 7 minimal
Error: Package: php-imap-5.4.16-3.el7.x86_64 (virtualmin)
Requires: libc-client.so.2007()(64bit)
Error: Package: perl-Net-Server-2.007-2.el7.noarch (virtualmin)
Requires: perl(IO::Multiplex) >= 1.05
Error: Package: postgrey-1.34-12.el7.noarch (virtualmin)
Requires: perl(BerkeleyDB)
Now at the end i made it work but still not sure if that was because i upgraded Centos 7 "minimal" to "base" or because i installed (and enabled) EPEL. Either way the installer could not finish even after multiple attempts until the last one when i upgraded my OS and installed/enabled EPEL.
Why Virtualmin is pushing for firewalld and not iptables or at least why we dont get an option during the installation? It could be that there is a way to do this /before/during the install but this option should be integrated in the default/main installation.
Why did you integrate PHP 7 for Centos 7 while we know this PHP version will be EOL in 7 months? Who in his right mind did think this is good idea? Now instead of just upgrading the default PHP 5.4 to whatever i want or make side-by-side installation you put even more work as now i must remove the PHP 7 (for the simple fact i dont want it). Why did you break your policy for Virtualmin to not touch the default software or at least make minimal impact? Freaking hand-holding never worked for anyone yet you decided how installing non-default and almost obsolete PHP version will be good idea...
I dont know from where did you pull that PHP but can i remove it with yum remove rh-php70*? I know how it works with Remi repo but not sure how did you install this version as obviously isnt from Remi. Is there anything in your Repo i should disable to prevent any future complications during updates?
Please share the light to my questions and just so you know this new installer is a failure. You dont have any right to chose what i will use on my server so please stick with your policy "minimal to none OS modifications" and leave the rest for us to decide what we want. If someone is so stupid to not know how to install side-by-side or upgrade existing PHP then he should pay someone for this job.
Comments
Submitted by andreychek on Thu, 04/05/2018 - 10:33 Comment #3
Passing this along to Joe for further comment.
In mean time you can dig out the information if i can remove PHP 7 by running
yum remove rh-php70*or there is more what needs to be done.This are simple questions and hope i dont need to wait 24+ hours to get the answer.
Speaking of PHP 7 how do you guys think to sort this when in 7 months this version reaches EOL? In mean time PHP 7 will not receive any updates or upgrades aside of critical bug patches what makes all this even more pointless. When you introduced this nonsense in Virtualmin 6 this version of PHP was already without active support - so you actually used (almost) obsolete version of PHP. Great job...
Do you have a question, or just want to rant? ;-)
The new installer is completely customizable, unlike the old one. People wanted it to do more by default, so I made it do more by default. Most people are happy with it doing more.
You can get exactly the installation you want by doing the following:
Setup the repositories:
# install.sh --setupInstall your preferred set of packages.
This installs the minimal set of packages (though it does still include firewalld, that's part of a default CentOS 7 installation, anyway, but you can ask for Virtualmin to configure iptables for you instead later):
# yum group install "Virtualmin LAMP Stack Minimal"Install Webmin and Virtualmin modules:
# yum group install "Virtualmin Core"Configure it:
# virtualmin config-system --include Whatever Pieces You Want ConfiguredI'd recommend you spend a little time perusing what the default config-system bundles are. You can see them by looking at the bundle source here: https://github.com/virtualmin/Virtualmin-Config/tree/master/lib/Virtualm...
There's also help for the config-system subcommand:
# virtualmin config-system --helpAnd, you can list the available plugins and bundles of plugins.
If there's a configuration you'd like to see, I encourage you to fork the Virtualmin-Config repo and add a new bundle. I'll even consider adding it as an option to the installer we ship, as long as it is self-consistent (i.e. I can readily make it work across all of our supported systems). Adding new bundles does not require you to know Perl. You just need to make a new file, change the name of the bundle object in the file, and make a list of the plugins to run.
Adding a new set of dependencies is a little more involved, but only a little bit. You have to create a new yum group, new dpkg metapackages (you can copy mine, and make very minor changes...you don't need to know how to make yum groups or metapackages). Again, if you create a self-consistent configuration bundle and yum group/metapackage, I'll definitely consider integrating it into the default installer that everybody gets (including you when you download it next).
As for the PHP version, people wanted PHP7. We included it; I don't really like it (I like using OS standard packages). We'll bump up to 7.1 pretty soon. I need to spend some time with it to make sure all the same dependencies are available and such. I can also provide an upgrade path for existing users, though there is no way to automatically push it out safely...there are potentially incompatible changes between 7.0 and 7.1, which users will need to make decisions about.
You can probably just run
yum remove rh-php70*, but I haven't tested that. Try it before you put the server in production and lemme know how it goes.But, I do recommend that if you have very custom needs you dig in and make Virtuamin-Config and the yum groups do the work for you (though you can do it completely custom without that...just specifically list the packages you want and the configuration you want, instead of using
group installand a --bundle in config-system command). It's also possible to use--excludeto run a bundle, but exclude specific modules...but, they'll be re-included if there's a dependency. I should probably make that result in an error instead of just pulling it in silently.Other links:
Yum groups: https://github.com/virtualmin/virtualmin-yum-groups
Debian metapackages: https://github.com/virtualmin/virtualmin-lamp-stack-deb
Install script: https://github.com/virtualmin/virtualmin-install
The great thing about open source is that when it breaks, you get to keep the pieces. And, you can also put it back together any way you like.
And, for the initial error that spawned your rant, I haven't seen that problem before. I'll do a test install today to make sure there isn't something new going wrong...because we include EPEL and SCL repos, it's much more likely for there to be dependency breakage related to our own packages, because the package compatibility policies of EPEL and SCL are much less strict than RHEL/CentOS core repos.
So in other words you didnt test how to safely remove PHP 7 after the initial installation? Really? Not for a second no one of you was thinking "what if someone dont want to have PHP7". Can i exclude this version of PHP from the initial install? And yes, i will let you know.
I just went to test new Hetzner cloud and this took me by surprise. Last time i installed Virtualmin was before 2 or 3 years on my test VPS (and i still have it). First the new installation i dont like at all, simply because i was more happy how it worked before. Then this error what make me lose at least half an hour. So we are speaking of fresh VPS based on KVM virtualization. First attempt was clean Centos 7 minimal without anything extra installed, still this error show up. But based on what you said looks like it was gone only after i manually installed EPEL. I suspected that this is the problem but because in the same time i made a upgrade from "minimal" to base" i was not sure which of this two made it work..
It was so easy to install additional PHP versions or just upgrade the default one so i dont see any point in making this a core part of the installation.
For the rest if one day i decide to go Pro i will take a look but right now there is no point. Still it would be "funny" if i went to install Pro for some of my client. To sure that all the install and setup will be done in no time and then find out that i must spend hours to find out the solution because of the mess you made.
If you really wanted to make it easy why not a new menu in Webmin with "one-click-button" for anything extra what people wanted to have. This is just pointless because it could be done much better than its now. You can like my opinion or not, thats entirely your call.
It's always been configurable within Virtualmin, and it's always been possible to install other packages and configure them after installation. People wanted the default installation to be more complete out of the box, so we did that. You are always welcome to go with other options. We're trying to answer the needs and wants of our users as best we can. And, as I mentioned, the installer and everything is uses are all open source.
Here's the thing I don't get about your complaint: The old installer was not configurable. Not even a little bit. You could not change anything about how the old installer worked. None. You couldn't choose different packages. You couldn't choose to skip some configuration or include others. You couldn't pick and choose the services you wanted. It did what it did, and then if you didn't like it, you'd change it after installation (and maybe run into some dependency issues, etc.).
The new installer provides many escape routes. You can choose to use our dependency list, or your own. You can choose to use our preferred set of configuration plugins, or you can exclude some or you can write your own from scratch and include them (just put them into the right place between installing "Virtualmin Core" and running the configuration step, any Perl module that properly subclasses the Virtualmin::Config::Plugin object will be available to you).
You're saying you want customization, which is what the new installer provides. You're also saying you want the old installer, which provided no customization, at all. I can't make any sense of that.
I've told you how to get the installation you want. It takes three or four commands, which you can put into a shell script, or you can make custom versions of the parts so it can be called with the usual
install.shcommand without needing to break it up into pieces. What you do with that information is up to you.I will happily fix dependency problems that prevent installation. But, I don't have any interest in re-litigating the new installer. The old one sucked; I wrote it and maintained it for over a decade, I can say that. New installer does everything you want; all you have to do is run a few commands.
Ok came back as i said i will let you know if it was possible to remove PHP7 and the answer is yes. Well at least it looks like everything works fine. Just in case you need this info:
1. Removed PHP 7 with
yum remove rh-php70*2. Installed Remi repo and updated default PHP 5.4 to 7.2
[root@hellbender ~]# php --versionPHP 7.2.4 (cli) (built: Mar 27 2018 17:23:35) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
The following PHP versions are available : 7.2.4 (/bin/php-cgi), 7.2 (mod_php)Just to make it clear if anyone have the same "problem" - this was done on clean install of Centos 7 and Virtualmin and doesnt mean it will work in your case.
About that problem with dependencies... I just paid for another VPS so i can keep the old one as reference and the problem didnt show up. Now comparing two servers they are literally identical so right now i dont have any clue why this was happening on first VPS but not on second. If you can figure this out ok but i'm not going to keep them for very long. It could be that something went wrong during the update (not upgrade) of Centos as did this before installing Virtualmin. This started as test for Hetzner cloud and ended in something completely different and honestly i already lost too much time on things i didnt want or plan. But maybe one day i could wipe out my (old) test server and take time to see in detail what is so great with the new installer.
Last but not least, i get what was your intention with new installer and you made few points that i agree, still you should keep the "old school" position to not modify the OS or if you do to have minimal impact. When i saw PHP7 on my server first thing to pop in my mind was "great, here we go cPanel wannabe". If you dont come up with some good plan i can see right now how many people will/could have problems when PHP7 reaches EOL.
If you need something let me know otherwise... /thread.