@olivierlambert @stormi

So I have been working on this repo for about a month now and it is in a far worse state than I ever imagined. I showed the codebase to some golang pro's and they pretty much roasted every aspect of the original source code. It uses multiple depreciated packages, breaks multiple best practices that golang considers to be fundamental to portability and future-proofing, has a complete lack of any documentation on a variety of esoteric calls, and the source code does not compile against GOOS=freebsd.

I was hoping I could just make some quick changes to clean up this repo for the XCP-NG community but this is a huge endeavor to get in a good place for the future. I would very much like to continue work on this but it has become clear to me that a small team of developers will be required to finish this in a timely fashion. I would suggest creating a new repo called XCP-guest-tools as a properly upgraded version of this repo would rewrite 40%-60% of the original source code to bring it up to a reasonable standard. I also think at that point it would be extremely unlikely that Citrix would ever merge the changes so splitting off to a newly named package would go a long way to avoid confusion about versions and source.

@ravenet Thanks so much! I'll add these examples to our new test case folder I will definitely be in touch when we are ready to test on SLES!

An Update on Progress:

I have a new collaborator working with me on reworking these tools which should help with development. He uses XCP-ng as well and is pretty familiar with all the OS's I'm currently planning on officially supporting.

Actual progress has been a little sporadic as we pull apart these tools. The complete lack of documentation has made auditing the Go tedious, as I personally am not familiar with the xenbus standard and/or the data-structure Citrix is using pass info to dom0. The more I pull apart this repo, the more I am questioning the sanity of the Citrix developers. My gut feeling is a lot of this is legacy code that no one wanted to fix or touch for that matter. At some point when we get closer to a proper release, I'll create a list of all the bizarre and poorly designed code we found.

We do have a working makefile and the tools do compile correctly into a generic package.tgz, but there are still a number of things that need to be fixed before it would function on a guest os. I'm also currently in the process of auditing the use of unsafe.Pointer( ) in the existing wrapper for 'timerfd_settime' calls. I'm not really sure why this was done and using the unsafe package is typically bad practice in any production code. It explicitly breaks Go compatibility guidelines and type safety which is kind of the point of Go IMO

I was trying to avoid making a Citrix account lol. (I have a strong distaste for them, for reasons I will cover below)

After digging through the Citrix repo, I have found somethings that frankly infuriate me. Citrix has really no desire to support the opensource community as seen in this comment and their total lack of responsiveness in fixing issues. For instance, this issue, opened and fixed by a member of the fedora team, has sat for over a year. They also have zero documentation anywhere in the code base, and from issues like this they have no intention of adding it. Citrix has abandoned the opensource model to try and compete with VMWare.

While I can understand your desire to maintain some relation with Citrix, I personally have no desire to help them. They have burned their goodwill with the opensource community and this is why, I assume, you started XCP-ng. Moving forward, my desire is to turn this repo into a peer-reviewed, well documented, and actively maintained repository. If Citrix would like to use the improvements XCP-ng makes that's fine, but I don't want my work to sit for years in a pull request that will never be merged by Citrix.

A quick update on progress:

• Added support in install.sh for OpenSuse
• Rebuilt the security audit process of go binaries from python2 --> python3.
• Improved the audit process pretty dramatically.
• Started patching 23 security issues found by the new audit process.
• Started adding documentation across the entire repo.

Up next:

• New package makefiles for the following package managers.
  - apt/dpkg
  - yum/dnf
  - zypper/yast
  - pacman
  - pkg
  - apk
• New test process for xe-linux-distribution

@olivierlambert @stormi

Having tests will be a great argument to become the new upstream

Our situation is different from that of any linux distribution that wants to provide the tools (which we encourage any distro to do), since what we provide is a RPM that contains an ISO that itself contains DEBs, RPMs, and others. It's not something we can easily build in our build system, koji (though there may be a way to manage it). So we've get to automate that build process.

This weekend I was able to finish the first tool I needed to help streamline the process of testing and building these tools. Its something I'm just calling PRT(Parallel Remote Terminal) for now. I currently have a number of testbeds in my cluster but testing manually on each is a huge pain. PRT is a tool that allows a user to define a group of remote hosts using a yaml file, then send the same command in parallel to each host. PRT returns the connection status, output, and errors on each host directly back to your machine. I hope you won't judge too hard on the quality of my code and docs because this was built in space of 48 hours lol.

You can check it out here:
https://github.com/JustinTimperio/prt

I'll clean this up and improve it over the coming weeks but obviously, this is just tooling to help facilitate the actual work of improving these tools.

Do you keep a list of all the distro's you support? I am looking at converting the shell into go, but I want to make sure I am accounting for the edge cases.

Currently, I am looking to officially support:

RHL:

• CentOS
• Fedora
• REHL (I don't have a copy to test on)

Deb:

• Debian
• Ubuntu
• Kali
• Mint
• MX
• Tails
• Kylin

Arch:

• Arch Linux
• Manjaro

BSD:

• FreeBSD
• OpenBSD

OpenSuse:

• Leap
• TumbleWeed

Random:

• Alpine Linux
• Gentoo

Hi All,

After adding support for Alpine Linux, I found the state of the xe-guest-utilities repo to be in pretty bad condition. This is mostly Citrix fault but at this point, I think XCP-ng has grown large enough that full rework is justified. The Go itself looks reasonable but has somethings worth changing. There also seems to be a large number of 'dead' files and a LOT of very poorly formatted and documented shellcode.

If anyone as an interest in me reworking this repo I can take a look at cleaning this up into something far more 'professional' and better suited for XCP-ng. I currently have a pull request submitted if you would like to look at the work I have done so far.

https://github.com/xcp-ng/xe-guest-utilities/pull/2

Best,
Justin

JustinTimperio opened this pull request in xcp-ng/xe-guest-utilities

closed Major Update To Guest Utilities #2