Best posts made by Wayne Workman

I sit on pages reading… you post fast, didn’t see your last post.

Glad you got it working.

You can disable a linux user’s ability to use a shell. Assuming the user account is called fog the command is:
usermod -s /sbin/nologin fog
or
usermod -s /usr/sbin/nologin fog

Something more elaborate that I found on the net would look like this:

touch /bin/nologin
chmod 755 /bin/nologin
echo '#!/bin/bash' > /bin/nologin
echo 'echo The fog account should not be used for system management.' >> /bin/nologin
echo 'echo Please create another account for system management.' >> /bin/nologin
echo 'echo This session will end in 15 seconds' >> /bin/nologin
echo 'echo Goodbye' >> /bin/nologin
echo 'sleep 15' >> /bin/nologin
echo '/bin/nologin' >> /etc/shells
usermod -s /bin/nologin fog

Changing the default username to something besides fog shouldn’t affect existing fog systems, since the username setting inside of /opt/fog/.fogsettings would remain in existing systems, and the username for existing storage nodes wouldn’t be touched.

A downside is all the documentation / screenshots that would become incorrect for new installations. There is a lot of content ‘out there’ about fog.

@MrKeishii Because you have an FTP problem.

This link is the original fog testing dashboard.
This dashboard was created to help identify problems with the FOG installation process early on, so they can be fixed before users experience them. This dashboard has been generally UP for about two years now. It’s served the FOG Project well.

However, the old dashboard was written mostly in BASH and is a mess. It requires custom setup, custom snapshots, hand-spun virtual machines, and a tremendous amount of compute resources and time. While the code that this dashboard uses is completely open source and available, due to the complex setup, nobody has bothered using it.

Thank you, old dashboard, You’re retirement party is coming up soon.

Hello new dashboard!

The new dashboard has several significant improvements over the old one. Notably:

• Mostly written in Python.
• 100% AWS based.
• 100% of the infrastructure is built via Terraform.
• Includes Red Hat Enterprise Linux 7 testing.
• Orders of magnitude faster to run.
• Makes logs available regardless of success status.
• New logs, and output - such as stdout from the fog installer, patching stdout, and php-fpm logs.

The new code base has been made available for all here and includes instructions for you to set this up for yourself, should you decide to run the FOG Installer tests yourself.

Features that existed in the old dashboard but were done away with (for now) are:

• Streak counts
• Log history.
• FogProject slack channel posts.
• Older OSs.

I plan to make testing history available in the future.

For a while, I plan to run the old tests and new tests in parallel until I’m sure the new tests are stable, bug free, and ready to be relied on. Then, the old tests will be shut down for good.

@Atton This is a common problem, and an easy fix. It’s most likely your FTP credentials that need fixed. Here is an article on it: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP

If you need further help, don’t hesitate to ask. We are here to help.

One of many examples of people getting mixed up by this: https://forums.fogproject.org/topic/12810/after-installing-fog-i-seem-to-get-locked-out-of-ubuntu

You’re on the right trail.

It’s likely that you’re just not using the correct EFI file or you don’t have the USB NIC parameter set. There are a few threads here in the forums, let’s see if I can find some…

This is a good one:
https://forums.fogproject.org/topic/5591/surface-3-and-fog-1-2/2

Here are some others:
https://forums.fogproject.org/topic/5689/surface-3-imaging
https://forums.fogproject.org/topic/4627/updating-to-svn-3121-setting-up-and-starting-tftp-and-pxe-servers-failed/17
https://forums.fogproject.org/topic/4994/windows-8-1-uefi-gpt-questions/2
https://forums.fogproject.org/topic/4981/surface-pro-3-imaging
https://forums.fogproject.org/topic/4982/unable-to-successfully-pxe-boot-to-a-fog-menu-on-a-microsoft-surface-pro-3/1
https://forums.fogproject.org/topic/3662/surface-pro-3-pxe/55

I’ve shut down the old tests, and switched the new tests to use fogtesting.theworkmans.us

@Rusty said:

Anything need to be backed up/recorded etc ?

If it’s virtualized, I recommend taking a snapshot before updating Trunk versions of fog.

If it’s not virtualized (and a production server), do a DB export (FOG Configuration -> Configuration Save -> Export) and a Host export (Host Management -> Export hosts -> Export) at minimum. Append the file names with the SVN version you’re using.

IF you decided to blast away the current build you have and start over, copy your images and grab a copy of /opt/fog because it has your SSL keys in it.

I made the changes and did a test run, dev-branch completely passed.

@Rusty Trade out patch cables, if you have more than one of these problematic dells I would suggest trying with another just to see what happens.

Are you using a managed switch?
Are DHCP Helper addresses set on the managed switch?
Is portfast enabled on the managed switch?

What if you created a reverse lookup zone and it worked more reliably?

A lot of things use PTR records. There’s no conformity. Printers sometimes, computers finding printers, computers with IP printers installed and drivers that want to use the FQDN, some client / server software uses PTR records. the list goes on.

I wouldn’t be surprised at all if the firmware on the device you’re using is trying to querry for the PTR record just to fill some internal system variable (whether it’s used or not).

as @george1421 said, it is good practice to have a reverse lookup zone. More stuff will work and you’ll have less mysteries.

Posting this as just informational. Seems to be some sort of problem with installing on Arch.

It seems to be the caused by a change in Arch Linux, not FOG, as installation of three different FOG branches are failing all on the same day today. I’ll keep an eye on it, and see if the same thing happens again tomorrow before I invest time into looking at it.

@george1421 In fact, this one part of the installer has had a lot of issues in the past.

instead of trying once and just giving up if it doesn’t work the first time - I think it should try again… at least 3 tries, just for problems like below where someone is trying to download the file over a crappy connection half the world away… @Tom-Elliott

I’m happy to announce the daily installation tests now include CentOS 8 and Ubuntu 20.04 Server. In addition to this, the reliability of the daily installation tests have been greatly improved. There’s now some retry logic for getting the result files from the test OSs, as well as a distinction now between being unable to get results vs installation not finishing in time.

Typically I’ll monitor that the new OSs are solid for a few days, and usually I remove the older OS versions afterwards. Though seeing that we’re talking about CentOS and Ubuntu, I may leave both because I know there are lots of people out there using CentOS 7 still, as well as probably many versions of Ubuntu. I’ll be able to make more informed choices about this after the FOG Popularity Contest is working.

The daily results link is in my signature.

I couldn’t imagine imaging with quick image… I would rather not work like a dog as I once did with Norton Ghost.

As @george1421 said, you need to try out the features of fog - You’re seriously missing out.

I can image 500 computers in one day with the features FOG provides. And I’m only one man, with only two feet… and I don’t even need to leave my desk to do it.

I know FOG Trunk (1.3.0 beta) has quick image, not sure about 1.2.0… I’ve never actually spent any time using 1.2.0. Quick Image will do what you’re asking. But I’d urge you to rethink how you’re doing things. The way you think you want is not better.

@george1421 said in FOG External Reporting:

I didn’t have access to the raw data only the chart

The DB is available for download on the same page. It’s just a mysql dump. The thing to bear in mind with the DB is the fog installer sets up servers (if they don’t opt out) to report in once per week, at some random time. So, to look at what figure we have for dev servers out there, the below is the correct MySQL query:
select count(id) from versions_out_there where creation_time >= NOW() - INTERVAL 7 DAY;
This can be seen in the source code here:
https://github.com/FOGProject/fog-community-scripts/blob/1d2faad47478a5ea3bebb0906f03b0c3ace4c510/external_reporting/external_reporting/do_web_tasks.py#L79

@george1421 Imaging uses NFS.

NFS is utilized for upload and download.

/images is mounted as read-only via NFS for download.

/images/dev is mounted via NFS as read/write for upload (after upload completes, FTP is used to move the image from /images/dev to /images)

Settings for NFS can be found in /etc/exports

Here’s a related article with lots of good commands and info in it: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_NFS

@Jbob said in FOG client on Mac OS X:

perhaps we could name it something like “Wait until users are logged off” and invert it, or have some (?) hover next ot it?

I like that idea.

@george1421 said:

No configuration that you can do with fog will help since the cisco dhcp server tells the client what to do next.

There is dnsmasq. We have an article on it. I’ve used it extensively at home until I got confident with ISC-DHCP.

@Jbob Done.

@Louis-CSUSA we are here now.