Sure, we can totally do it that way.
Fixing MYSQL_OPT_RECONNECT warning by choosing the right Perl DB driver (DBD::MariaDB vs DBD::mysql)
2 Likes
Can we create a specific application without a preference? I mean, for MySQL, we use DBD::mysql, and for MariaDB, we use DBD::MariaDB.
We recommend installing either one depending on which database is currently used, and always use the package manager instead of CPAN.
Regarding CPAN, webmin should use a package manger package if one is available for the Perl module.
If a new modular Webmin (core install, not full) is used, where unnecessary modules like CPAN are not installed by default, it simply won’t work.
Hmm, maybe we should make sure the CPAN Webmin module is always available then. Because it contains all the logic to install Perl modules from any source.
I understand. But I will rather send you a patch later to do it without CPAN still, because we shouldn’t let users to install anything from source on a production system easily. And, considering we know the package names and they are already available, it would be better to directly to try to install it using software module.
1 Like
Implemented here:
This excludes a bunch of OSes. All the BSDs, the children of Solaris, any Linux that isn’t EL or Debian-derived, right?
I’m very much in favor of making installation from CPAN a last resort, and something worthy of a big warning to the user that they’re doing something kinda dangerous if it’s a production server (heck, having a compiler on a production server is kinda dangerous, and I’m guess MySQL bindings need a compiler), but, it shouldn’t be impossible to do it that way.
Do you mean my patch? If so, no, it doesn’t really. It tries CPAN from the start as before, and if it’s not installed, it uses the software module as a fallback.
Maybe we could add more package names from different distros to the map to make it work on more systems with software module.
Oh, wait, but why CPAN first? CPAN should always be the fallback and not the first choice.
Because, as it used to be, it can potentially cover more systems with other package managers. Webmin worked by trying to install using the package manager first, even when using CPAN. In Webmin core, we won’t have CPAN, so the new code will work for EL and Debian systems, and now FreeBSD too.
@Ilia please undo that commit - it’s just re-implementing logic we already have in Webmin’s cpan module, which looks for a package first and then falls back to real CPAN. You can see that code here : webmin/cpan/download.cgi at master · webmin/webmin · GitHub . And it uses the software module, which in turn knows how to call YUM and APT.
I can undo it, no problem. But can you explain why first?
And, yes, I’m fully aware that we are using similar logic in that patch.
I’m completely familiar with this logic and the code itself.
Why do you want to remove it? If the cpan module won’t be installed by default in a new Webmin core package, the user will never get a message about missing package. I understand that we will pre-install everything correctly using Virtualmin, but it shouldn’t depend solely on the installer.
So the fix is simple then - we just make the cpan module part of the webmin core package! That way we aren’t duplicating logic and code that already exists. To me, that’s far far more important and maintainable than keeping the core package small.
1 Like
Yeah, Webmin is a predominantly Perl project with a bunch of Perl dependencies, it makes sense to keep CPAN in core. (Even if we’d much rather get all deps from apt or dnf or whatever native packages.)
@Joe, we position ourselves as not building software on production systems, especially for Virtualmin users, some of which will do the wildest things imaginable, and we really don’t want to invite or normalize “compile on the server” workflows that can break the system or make it harder to support.
And, Webmin being Perl doesn’t change that, Linux has tons of Perl projects and none of them require you to build software on the machine as part of normal use.
@Jamie, I don’t think we’re duplicating code here. Also, CPAN shouldn’t be the one doing this—the package manager should. The right fix is to refactor so the software module owns this logic and can handle it cleanly on its own. And honestly, I’m not even sure what code you mean by “duplication”—I’m already just calling an API in the software module. If there’s real duplication, point me to it and I’m happy to make it more portable and/or less redundant.
But using CPAN in this case (when we already know exactly which packages we want) is the wrong entry point! It also covers 99.9% of Virtualmin users already, and having a CPAN module that compiles stuff on production boxes, and implicitly encouraging users to do that, is not something we should do or even remotely steer them toward.
So no, the Webmin CPAN module shouldn’t be in the core Webmin package. It’s just not a safe approach or a safe thing to do.
Jamie, tell me how you want it done. I’m firmly “package first” by default. Using CPAN as the doorway to install packaged system software just isn’t great design these days.
Short term, I can unroll the code and let the Virtualmin installer do it. But that still doesn’t solve the current issue, which is we end up with a CPAN dependency even on systems where the package is 100% available.
So the CPAN module is just responsible for installing Perl modules, and can handle either fetching them from YUM or APT, or compiling from the downloaded Perl source. I really really strongly do not believe this needs to change - the current functionality works, and has worked for a long while now.
Other than reducing the size of a future Webmin core package, what do we gain by moving this logic out of the cpan module? From what I can see, we’re actually reducing functionality because installing DBD::mysql on systems that don’t have a native package for it will no longer work.
1 Like
We expect a system without the cpan Webmin module, which is only happens in the Webmin core package, to always have it available through the package repository. My patch makes the code try to use CPAN first as before. If it can’t find the CPAN Webmin module, it falls back to using the software module with DNF, APT, or PKG, which covers all systems we support.
That said, it just makes sure that we don’t rely on Webmin CPAN and can install desired packages from the package repository.
Ok I get that, but why add this code when we could instead just include the cpan module in the core package? There are actually several other Webmin modules that check for and install Perl modules, like postgresql
Because this module can potentially build software, Virtualmin users might easily misuse it, and will. This is an advanced tool meant for experienced admins, not for users running WordPress sites. It should’t be installed by default.
That will be easy to address, as we already know the package names.
I suggest we make CPAN a fallback and only if it’s installed.