search

xcp-ng / xcp

Entry point for issues and wiki. Also contains some scripts and sources.
https://xcp-ng.org
1.31k stars 74 forks source link

List of useful extra packages for dom0 #56

Open olivierlambert opened 6 years ago

olivierlambert commented 6 years ago

We should be able to allow people to download directly some "extra" packages that can be really useful.

The only downside is that we'll need to synchronize any package update from CentOS to XCP-ng.

Monitoring

General

Security

UPS

Misc

If you have ideas of stuff that you'll like, let us know here

windgmbh commented 3 years ago

I do agree that wireguard is a very desirable package for Dom0.

wireguard is best used as a kernel module. Unfortunately this is not included with the Linux Kernel until Version 5.4. Below that, things become be a little bit harder, but are very well documented.

EDIT: Because xcp-ng is running a non-standard kernel wireguard would need to be implemented as a dynamic kernel module (wireguard-dkms).

# yum install dkms wireguard-tools --enablerepo=epel
# curl -o /etc/yum.repos.d/jdoss-wireguard-epel-7.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo
# yum install wireguard-dkms

EDIT-2: Unfortunately it is not that easy: the DKMS module will not build properly: 

error: redefinition of 'skb_mark_not_on_list'

EDIT-3: Apparently kernel-alt will work, but requires more workarounds than anyone would be comfortable with:

# yum install kernel-alt kernel-alt-devel kernel-alt-headers
# reboot 
# yum install dkms --exclude=kernel-devel --enablerepo=epel
# rpm -Uvh --nodeps $(repoquery --location wireguard-dkms)

I would prefer not exposing any detectable TCP/UDP ports on the hypervisor, which is exactly what Wireguard offers. Furthermore it could be a more simple/ modern alternative to IPsec.

Fohdeesha commented 3 years ago

As discussed in mattermost, basic network debugging packages will be a huge help to support and end-users, as during network issues you typically don't have network connectivity to "yum install" extra packages to begin with - so they need to be included in the base ISO. The following list covers almost everything we've needed to do for basic network troubleshooting on a host, and none have other dependencies. total size for all packages is ~4mb. None install or modify any kind of services and only do something when called:

bind-utils
iperf3
traceroute
nmap
nmap-ncat
mtr
nagilum99 commented 3 years ago

It's a bit more work, but instead of adding them per default, one could make a meta support-package that includes these and could be installed if needed. Of course it's only helpful if updates work.

stormi commented 3 years ago

What if we added them to the installation ISO but without installing them by default?

Fohdeesha commented 3 years ago

What if we added them to the installation ISO but without installing them by default?

I'm not sure I understand the difference? The end result that's desired is having these packages installed and ready to use in a finished XCP-ng installation. They are very tiny, in fact they come pre-installed in the majority of *nix distros these days - I believe the included docu/manpages for them are actually larger than the binaries - all of them total are less than 3mb. They're also all in our repo already

jotihojr commented 3 years ago

I would prefer these to be installable, albeit not installed by default.

Fohdeesha commented 3 years ago

Do you have a reason?

jotihojr commented 3 years ago

Our servers our locked down on a separate VLAN and have no access to nor can be accessed through our "regular" administration networks.

I believe, those who require these tools should be able to install them. However, those who don't, shouldn't be forced to purge them from the system.

Fohdeesha commented 3 years ago

Why would you purge them? They are never called, ran, or accessed unless you choose to do so directly. If you're looking to purge things, there are single packages that you've probably never touched in our installer that are bigger than the entire list above combined: smartmontools, sg3_utils, ipmitool, geoip, etc. Let alone debug packages like dyninst that are 10x the size of all the above packages combined. I can't think of many modern linux distributions that don't include at least a majority of the requested tools, they are quite basic. I'm open to any solution that allows a user to use the network testing packages above without needing a network connection first to grab them - however I think the space/purge angle is a bit odd considering what we're already shipping on the ISO

jotihojr commented 3 years ago

No one may have access to superfluous tools. We use all of the above except geoip daily/hourly, and geoip was purged. On our development system only necessary optional tools required for development purposes are installed. On our verification systems only the necessary tools and the like are installed, as in production.

Everything we do not have to think about is a blessing. If we could install the XenServer servers with cloud-init or the like; picking and choosing the required packages, I would see no problem.

aixtemaadmins commented 3 years ago

We use zabbix for network monitoring

the version 5 for zabbix agent cant be installed

but the Version : 4.4.10 can be smooth installed via rpm.

stormi commented 3 years ago

We use zabbix for network monitoring

the version 5 for zabbix agent cant be installed

but the Version : 4.4.10 can be smooth installed via rpm.

EPEL has zabbix40-agent-4.0.29-1.el7.x86_64.rpm whose only added runtime dependency is zabbix40-4.0.29-1.el7.x86_64.rpm. So you can install it with yum install zabbix40-agent --enablerepo=epel. No guarantees and usual warnings about additional packages, of course (https://xcp-ng.org/docs/additionalpackages.html)

kevdogg commented 3 years ago

Could you add dig or nslookup? Thanks -- just a suggestion

** Guess these are already included in the bin-utils package. Sorry to waste your time.

tacerus commented 3 years ago

@windgmbh Thank you very much for your instruction! They've been extremely useful. One caveat is that upon rebooting after the install of the alt kernel one needs to explicitly select it in GRUB! By default the regular kernel is selected - I only noticed after some errors with dkms. :-) I will manaually adjust the GRUB config to set the kernel-alt option as my default choice.

stormi commented 3 years ago

One caveat is that upon rebooting after the install of the alt kernel one needs to explicitly select it in GRUB!

It's documented, by the way: https://xcp-ng.org/docs/hardware.html#installation-on-an-existing-system

exu-g commented 3 years ago

I had a quick look at userspace implementations of wireguard and what it would take to run one of those. Both implementations I'm aware of (wireguard-go and wireguard-rs) would require newer versions of glibc at least. (The current version is 2.17)

These are the error messages I get when trying to run the binaries. (Compiled on an Arch Linux box. No idea if that could cause higher glibc requirements. I'll try compiling on a more stable distro later and see if that works)

Wireguard-Go would require glibc 2.32: ./wireguard-go-bin: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by ./wireguard-go-bin)

Wireguard-RS I'm not 100% sure, but to me it appears to need at least glibc 2.18:

./wireguard-rs-bin: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by ./wireguard-rs-bin)
./wireguard-rs-bin: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by ./wireguard-rs-bin)
./wireguard-rs-bin: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by ./wireguard-rs-bin)