Posts made by Wayne Workman

The number keeps going up, we’re at 233 dev users now.

I’ve added some more steps that should avoid those errors.

I’ve updated the chown command in the wiki. The user fogproject is something that came about after this article was written. The user used to be just fog

@george1421 said in Fedora 33 and Ubuntu 16:

I think there is surely a value in creating a supported operating system list for the FOG project.

Agreed. Though @Tom-Elliott wants to get everything OS agnostic by replacing PHP components with NodeJS ones, getting the UI and API away from making native OS calls, so on.

It’s a good plan, but a ton of work and probably years away. In the mean time, we could limit scope of the installer script by choosing a handful of OSs.

I’m having a lot of problems integrating Fedora 33 into the daily tests. This has been the reason for the lapse in testing here this last month.

I use Debian 10 as a bastion host, and use SSH Proxy Jump through Debian 10 to get to the other OSs. This has worked with every other OS that I’ve added. The Terraform configuration for Fedora 33 is here.

It’s not working for Fedora 33. I’ve gone over this issue probably a dozen times. Manual tests of this functionality work fine, so I’m unable to reproduce the problem. At this point, I need to leave Fedora 33 behind as there is value being lost in not testing the other more-popular OSs.

Good news is I’ve added Ubuntu 16 to the daily tests. This is because it’s still quite popular among dev-branch users.

Ubuntu 16.04 End-Of-Life is April 30, 2021. I suggest on this date the FOG Project drop support for Ubuntu 16.04 entirely. I urge the community currently using Ubuntu 16.04 to move to something newer.

I’m also down with making a Ubuntu image. Since that seems to be most popular. I wouldn’t want to mess with more than one.

A docker container is a good idea.

I was thinking with a VM image using Debian, I could pull down the packages FOG needs locally, and set apt-get to use those local packages. All the packages would also be pre-installed in the image.

As far as running something first-boot, if I’m building it I wouldn’t set it up like that. I’d say the admin can log into the VM (however they do that), and just run the fog installer which would already be there for them.

With this approach, there’s no changes to the installer or the code base. I hoped to automate building this image, creating a new one with each FOG release, and distributing via torrent.

If admins want to update, they would need internet and comment/uncomment some lines in their sources.list file, and update the fog repo with git pull.

Because the OS would be a chosen one, I can write up some documentation on setting a static IP, as well as putting a readme in the image saying the same.

Though a docker image is good too. idk if it would be easier or not. I don’t know docker very well.

It is probably really wasteful for nothing more than a FOG server, but you can mirror RPM repos really easily and host them locally for systems to access. I’ve done this before. I can say I had more problem’s with RHEL’s repos than any other. Sometimes packages there would simply be missing. Never had this issue with CentOS or Ubuntu repositories (which I’ve also mirrored and hosted locally).

Yeah, at this point Fedora would be a better pick for RPM based Linux than CentOS.

I think people should learn Debian. It’s not that big of a jump. The more you know about Linux, the less the distro matters. Tons of stuff online about Debian that you can search for any need you have. Main difference is apt-get vs dnf vs yum.

How to install git on CentOS:
yum -y install git

How to install git on Debian:
apt-get -y install git

So much difference…

The community likes Ubuntu a lot. I’m assuming most of these are probably from Europe, as Linux is popular there and there’s a decent FOG following in Europe. I would not choose Ubuntu for a server OS simply because of the automatic update stuff it does by default. At every company I’ve ever worked at, patches are a very, very controlled event. Down to the day, when it starts, when it ends, what’s being applied. We’d never put a server on cruise control.

Back to topic: An appliance based on Debian is a good idea. The build process should be automated, I can help with this. I have a decent internet connection at my house. I can distribute the image as a torrent (wouldn’t be very big). Others can help host if they choose due to the nature of the torrent system.

Someone out there has already installed FOG on CentOS Stream. I guess they know what they are doing, as I’ve not tested it at all.

Just today, I noticed a Ubuntu 14.04 user!!

The daily figures have been holding strong at 155 for about two weeks now. The number of active dev-branch users is likely very close to this figure.

Inactive dev-branch users, or users that don’t update to the latest dev-branch frequently, is likely a larger number.

If your boss asked you to do this within this time frame, you should push back.

@david201 You might be better off getting this out of Docker. Here are steps on how to migrate FOG. If you have the right switches enabled in the hosting OS, you should be able to mount NFS inside of the container. Otherwise, there are other ways to get the images & things out.
https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

FYI, there is now a tool that can renumber your images for you, here it is:
https://github.com/FOGProject/fog-community-scripts/tree/master/RenumberImageIDs

These graphs are from the new FOG Reporting. They are updated every hour. Link to the full dashboard is in my signature.

Tried emailing chuck, he has not replied. For now, I’ve removed all of the fogproject.org references, and HTTPS is working directly (redirect does not work). This is fine until Chuck can help with the DNS records.

@sebastian-roth Right, the alias is fine, please leave it as-is.

I tried without the subject alternative name and got browser errors related to SSL. The front-end is in AWS CloudFront, which uses AWS ACM for ssl certs. I can’t make a cert with the fogproject SAN in it without the verification. Right now, it’s not set-up as I figured we wanted to get the redirect working right. If that can’t be done, no big deal.

@Sebastian-Roth if you can get an A record created for stats-api.fogproject.org with a value of 3.20.18.241 I can get the ssl cert and such fixed on my side (using lets encrypt). Once that’s all done, we can update the reporting script to use the new URL.

For the results to have a good redirect from stats.fogproject.org, I need the SSL cert to include that subject alternative name. Please create this record, it’ll allow me to create that SSL cert. These values below are not secrets, and they will timeout in 72 hours from now (sometime wednesday). if it’s not made by then I can get new values. This is part of how AWS verifies the cert your making is legit.

Name:
_395058431eb78e5f8f9cc2478adbdfa3.stats.fogproject.org.

Type:
CNAME

Value:
_ee8469a4f9a938de348ef383be83b11f.zbkrxsrfvj.acm-validations.aws.

If this can’t be done for whatever reason, I can use the original results URL and it’ll work fine, just redirects from stats.fogproject.org won’t work.

Here’s the changes on the cloud side if you were interested.

@Sebastian-Roth So when I try:

curl -X POST -H "Content-Type: application/json"  -d '{"fog_version":"testing","os_name":"testing","os_version":"testing"}' https://stats-api.fogproject.org/api/records

This is the result:

curl: (6) Could not resolve host: stats-api.fogproject.org

Yeah the back-end only takes entries, nothing else.

The frontend url is less important, as that’s not needed in the fog codebase anywhere. It’s just a place one visits to see results. I can get HTTPS setup for it.

Sounds good.