Comments (63)
Yes, of course! Testing it right now. I don't know about all systems but I only care about CentOS 7-9 and Fedora. I think this is all we have to support?
from virtualmin-install.
So, to make this happen, @iliajie we need to confirm that all the packages in this universal binary repo work on every distro you want to support, and that the groups (LAMP and LEMP stacks) are correct for every distro you want to support.
from virtualmin-install.
If we have missing packages currently listed in the groups on some distros, we need to decide if we want to remove that dependency or provide that dependency in our repos (if the OS provides a newer one, it should be fine...since we're histrorically mostly pulling from Fedora when we need a package not in RHEL or EPEL, though I don't know if that's any longer a concern).
ClamAV is going to be a pain in the ass, just because it is always a pain in the ass. I don't know how or why yet, but I know that it will be, somehow.
from virtualmin-install.
we need to confirm that all the packages in this universal binary repo work on every distro you want to support
It doesn't for jailkit
- fails with dependency error pyhton_paltform
, if I remember correctly off-hand.
We need to handle not setting up EPEL during install
That is already done right, tested and working (at least with latest PR)
This will break everybody who's already done a Virtualmin 7 install. But, it's a beta, so we can ask them to update and tell them how. Or I can make links from the old repos to the new.
Having symlinks would be fine for some time.
but the PR to do that also replaces release packages with a bunch of shell scripting, which is bad).
Already reverted back on the PR to using release package.
Will it be OK across all supported distros to use the same one?
Fedora has different set of package. CentOS Stream too. Very slight but different. I think we can just add few extra more package to default stack for all RHELs, like wanted cronie
by Fedora.
If we have missing packages currently listed in the groups on some distros, we need to decide if we want to remove that dependency or provide that dependency in our repos (if the OS provides a newer one, it should be fine...since we're histrorically mostly pulling from Fedora when we need a package not in RHEL or EPEL, though I don't know if that's any longer a concern).
I will review and add a single file to yum-groups that must cover everything for all distros. (like today)
ClamAV is going to be a pain in the ass, just because it is always a pain in the ass. I don't know how or why yet, but I know that it will be, somehow.
Also will check, but presumably won't be a big problem.
Tell me how do you want to call the repo (URL) so I can add it to the PR to download correct release .rpm file.
from virtualmin-install.
One other concern Ilia raised in conversation is that Virtualmin's internal upgrade to Pro feature modifies the repo files directly rather than installing a new release package. And, even if we made it work the right way, it'd still end up making an .rpmnew
file instead of replacing with a Pro version of the repo file(s). This is also an issue on running ./install.sh --setup
unless the repo package is removed first.
Ideally the Virtualmin internal upgrade would remove the GPL release package and install the Pro one, rather than modifying the file directly.
Another improvement would be if auth details could be stored outside of the repo file, but I don't believe that's possible for HTTP basic auth. I'm looking into it. Maybe somebody else has a clue...
from virtualmin-install.
Repo path can just be rpm
, perhaps?
from virtualmin-install.
Oh, but we need architecture in there, too, since we want to support ARM at some point soonish. Umm... I dunno.
Maybe: https://software.virtualmin.com/vm/7/rpm/$arch
?
from virtualmin-install.
Oops, I forgot the Virtualmin version, which is needed to determine which signing keys are used.
Also, I'll make this work without auth, so it won't need a separate repo for Pro and GPL.
from virtualmin-install.
Ideally the Virtualmin internal upgrade would remove the GPL release package and install the Pro one, rather than modifying the file directly.
This is for later please.
Oh, great. I wanted to suggest VM version number. Looks fine!
from virtualmin-install.
Also, I'll make this work without auth, so it won't need a separate repo for Pro and GPL.
Sure, great!
from virtualmin-install.
So the full link would be:
https://software.virtualmin.com/vm/7/rpm/virtualmin-release-latest.noarch.rpm
Correct?
I'm working on merging yum-groups
now into a single file. Looks very promising for all CentOS 7-9 + Fedora - packages are there.
from virtualmin-install.
Fedora has different set of package. CentOS Stream too. Very slight but different. I think we can just add few extra more package to default stack for all RHELs, like wanted cronie by Fedora.
Which packages? Why are we wanting cronie?
from virtualmin-install.
Yeah, cronie
but it's available on all distros CentOS 7-9 - so, all cool!
from virtualmin-install.
Why are we wanting cronie?
from virtualmin-install.
Cron module?
from virtualmin-install.
Oh. Is that not in the core OS?
from virtualmin-install.
I just assumed cron was something we could always rely on, on any Linux system.
from virtualmin-install.
And, for the package name/path, I don't know exactly, yet. I'm considering splitting it into two, one for universal packages (which needs auth for Pro repos, but doesn't need anything for GPL) and one for binaries (which never need auth for either Pro or GPL).
Not sure what to name them. They're both gonna be "universal" in some sense.
from virtualmin-install.
Maybe virtualmin-universal-release
and virtualmin-arch-release
? Does that seem sensible, to you?
And, they could be stored in their own path at, like /vm/7/rpm/release
so they don't have to have $basearch
in the path when downloading them and don't need to be maintained separately.
Would we ever need to update these packages? I guess if there was a key invalidation and we needed to roll new keys...maybe I should make this a repo, too, so users can update their release packages.
from virtualmin-install.
We can never rely on anything. Some distros don't have tar and rsync. what kind of linux system is this without those.
I will handle this.
So, question -
<packagereq type="default">perl-lib</packagereq>
Will try to install but won't fail, correct?
Added to PR using a new releasever free .rpm.
from virtualmin-install.
lol, I went to create a repo for this, and found I already have a virtualmin-release repo. I'd forgotten about it. It's not up to date. But, I'm refactoring everything anyway... https://github.com/virtualmin/virtualmin-release
from virtualmin-install.
OK, I think I actually want to do:
virtualmin-universal-release
- for the pure-Perl Virtualmin modules and Webmin/Usermin, etc.
virtualmin-release
- for the binaries
from virtualmin-install.
so, to files?
from virtualmin-install.
Oh, wait! I have a better idea.
virtualmin-universal-gpl-release
and virtualmin-universal-pro-release
This solves the problem of Virtualmin updating the repo files directly! and Very clearly states in the package name which repos are used!
from virtualmin-install.
Okay. Let me fix the PR then.
from virtualmin-install.
Wait, stop making PRs until this is settled!
We need a minor change to the Virtualmin upgrade process.
@jcameron can you make it so the Virtualmin Upgrade to Pro feature handles upgrades via packages rather than via updating the yum repo
files directly, if the virtualmin-gpl-release
package is installed? You can then just install virtualmin-pro-release
which will replace the repo file with a new one. Still need to update the /etc/virtualmin-license
file to include the serial and key.
from virtualmin-install.
Well, this won't solve change license process?
from virtualmin-install.
Wait, stop making PRs until this is settled!
Those are commits to the PR. :)
from virtualmin-install.
Well, this won't solve change license process?
But, it will, though? Two packages that conflict with each other very gracefully solves the problem of rpmnew
files being generated, and handles the upgrade process without anyone every touching a repo file with a script. (The small script to set the auth details is bundled in the package, as it's always been, but Virtualmin no longer needs to care.)
from virtualmin-install.
I meant virtualmin change-license
command.
from virtualmin-install.
Ah! OK, in the change-license case, I think it's fine to hit the repo file directly.
That's never an upgrade/downgrade to/from pro/gpl, right?
from virtualmin-install.
But, it'll need an update to recognize the new paths. Unless I make the repo file name stay the same for the Pro/GPL sensitive version. e.g. virtualmin.repo
contains the universal
Perl packages, which includes auth and has Pro or GPL version of package, and then...I dunno what I call the other one.
from virtualmin-install.
No, change-license
cannot do upgrades.
How is the package for Pro users is going to have the correct key/serial on the package? Upon download time or it will be fixed afterwards on the system?
from virtualmin-install.
Oh, would also be possible to remove the release package and install it again...
from virtualmin-install.
Will be fixed at package install time (this is suboptimal, but the alternatives are worse). But, we no longer have to worry about rpmnew when switching from pro to gpl or vice versa if the package names are different.
from virtualmin-install.
But, it'll need an update to recognize the new paths. Unless I make the repo file name stay the same for the Pro/GPL sensitive version. e.g.
virtualmin.repo
contains theuniversal
Perl packages, which includes auth and has Pro or GPL version of package, and then...I dunno what I call the other one.
Maybe as both repos are needed for all installs we could place them into a single package?
from virtualmin-install.
Maybe as both repos are needed for all installs we could place them into a single package?
OK, I guess we can do that. But, I still think I want to split out the repos into their own files, so one of them never gets updated. It'll be exactly what's in the release (no license info). Maybe not necessary though if the binary one includes the $basearch
variable so it can be the same two release packages.
Yeah, I think that works. So, we have either virtualmin-pro-release
or virtualmin-gpl-release
which both produce a file called /etc/yum.repos.d/virtualmin.repo
containing both the perl repo and the binary repo.
from virtualmin-install.
Need to test what happens when installing GPL release over Pro release, to be sure RPM will allow it to replace a modified file. I think it'll make it rpmsave
, which is fine.
from virtualmin-install.
OK, if no complaints about that, I'm going to branch and make two new release packages for this, and start making the new repos.
from virtualmin-install.
@jcameron, if you're following along, I updated the package name above (for the part that applies to you and the Virtualmin upgrade to Pro feature).
from virtualmin-install.
Yeah, I think that works. So, we have either virtualmin-pro-release or virtualmin-gpl-release which both produce a file called /etc/yum.repos.d/virtualmin.repo containing both the perl repo and the binary repo.
That's fine!
Need to test what happens when installing GPL release over Pro release, to be sure RPM will allow it to replace a modified file. I think it'll make it rpmsave, which is fine.
I think it won't replace it, particularly if that virtualmin.repo
was modified. May be just don't make it a %conf
file and just forcefully remove each install/re-install?
OK, if no complaints about that, I'm going to branch and make two new release packages for this, and start making the new repos.
Alright, I'm building a new virtualmin-comps.xml
to work across all systems.
from virtualmin-install.
It's a different package. It's not upgrade/downgrade.
from virtualmin-install.
Are you sure about clamav being the same package name(s) across all supported distros/versions?
from virtualmin-install.
Also weeded out clamav
being installed on minimal..
from virtualmin-install.
Why are we depending on chrony
? https://github.com/virtualmin/virtualmin-yum-groups/blob/401dbf6a8a4d81eae24f4337b213b421e1cca43b/virtualmin-centos-8-comps.xml#L47
We shouldn't be making decisions about how people set time?
from virtualmin-install.
This is not a dependency. It will try to install. It's an awesome and new way to sync time.
Like:
systemctl restart chronyd
from virtualmin-install.
We shouldn't be making decisions about how people set time?
As far as I remember right now, there is no other way for CentOS 8+ to do it.
from virtualmin-install.
.. and I made Webmin support it too.
from virtualmin-install.
systemd-timesyncd is everywhere now. But, I guess chrony is the default on RH/Fedora. Seems like if somebody is already using timesyncd, this would replace it. But, I don't guess anyone has complained in the two years since you made that change.
from virtualmin-install.
Yeah, chronyd
is fine for RHELs. Although, I like systemd-timesyncd
but widely it only works with Debian systems.
from virtualmin-install.
New version of install.sh
script will use both to force sync user time, to avoid issues with installing proper ca-certificates
package.
from virtualmin-install.
All done with comps - virtualmin/virtualmin-yum-groups@41913c6
from virtualmin-install.
Must work on Alma, Rocky, CentOS 7-9, Fedora and RHEL. Even probably Oracle 8 too.
from virtualmin-install.
OK, I guess we'll find out in a couple of hours when I'm finished pushing the new repos.
from virtualmin-install.
Alright. So we stick with:
virtualmin-universal-gpl-release
and virtualmin-universal-pro-release
, correct?
from virtualmin-install.
No. virtualmin-gpl-release
and virtualmin-pro-release
See above.
from virtualmin-install.
Since we're only doing one repo
file, they can have one release
package.
from virtualmin-install.
Yeah, yeah. I actually meant that but copy paste from strings.
from virtualmin-install.
Okay, all done - ca59e86
from virtualmin-install.
Forgot login and host. Fixed - 6c981c1
from virtualmin-install.
Here's the PR for the release packages. I'll build/test before merging.
virtualmin/virtualmin-release#1
from virtualmin-install.
Alright. Please test using install.sh
from my PR.
from virtualmin-install.
Done.
from virtualmin-install.
Related Issues (20)
- virtualmin backups with ssh on an alternative port number HOT 3
- Virtualmin installer doesn't present the correct IP address HOT 3
- Virtualmin installer doesn't properly identify quotas
- Virtualmin installer complaints about unknown package not being installed. HOT 2
- error 100 on ubuntu 22.04 HOT 9
- LEMP stack wants to install apache2, breaking websites. HOT 3
- Installer script returns exit code 1 on success HOT 1
- Installation fails on ubuntu 22.04 HOT 7
- Input from keyboard not working with the latest installation script HOT 4
- script not interactive? HOT 4
- Keyboard local echo is off after answering no to "Continue? (y/n)" HOT 1
- Option to install MySQL instead of MariaDB HOT 9
- RHEL 9.1 installation issue - installation hangs at [4/21] Configuring ClamAV HOT 5
- Rename `install.sh` to `virtualmin-install.sh` everywhere HOT 2
- Unable to determine IP address of primary interface. HOT 5
- Install script fails on Debian 11.6 (no /etc/webmin after webmin package instalation) HOT 7
- Autoreply mail enabled -> unknown user HOT 39
- MySQL instead of MariaDb HOT 6
- Give the possibility of choice between MariaDB and MySQL suite HOT 15
- Problème avec la mise à jour de webin et usermin HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from virtualmin-install.