You should only reset encryption for a host when you’re having problems with it, generally.
Posts made by Wayne Workman
-
RE: reset encryption data
-
RE: Not able to PXE boot from Raspberry Pi 3b
@jweeks Need to know more about the host model you’re trying to boot. Also need to know more about your network. Is your router already serving out DHCP?
-
Alma 9, RHEL 9, Fedora 36, Ubuntu 22.04 added to daily tests
Alma 9, RHEL 9, Fedora 36, Ubuntu 22.04 have been added to the daily tests. Link to daily results dashboard is in my signature.
If you are wondering, Rocky Linux has not yet released Rocky 9.
Master branch looks pretty rough right now, but dev-branch and working-1.6 are all-green.
-
RE: Quick Question: Does FOG require IPv6?
@brakcounty Pretty sure it’s not required.
-
Debian has surpassed Ubuntu
Thought I would never see it, but it’s happened. Debian is now the most-popular Linux operating system for FOG dev-branch and working-branch.
The figures as of today:
"Debian": 295, "Ubuntu": 290, "CentOS": 128, "CentOSStream": 5, "Rocky": 4, "AlmaLinux": 3, "RedHatEnterpriseServer": 3, "Raspbian": 2, "LinuxMint": 2, "Fedora": 2, "OracleServer": 1
These figures are from fog’s external-reporting functionality. A link to the dashboard is in my signature.
-
RE: Removal of Fog user in Fog Project
@zfeng Glad you figured this out. When you find a contradiction, check your premises. You will find that one or more is incorrect, or they are incomplete.
-
RE: Reinstating Images to the Web UI
@mgoh You could probably update the size with a sql command if you wanted. Not really a need to do it though.
-
RE: mysql open ports on FOG server
@brakcounty I’d suggest doing some internet searching before asking general linux questions.
https://duckduckgo.com/?q=ubuntu+ufw+default+rules&t=ffab&ia=web
First result and second result both have the answer.
-
RE: Reinstating Images to the Web UI
@mgoh If you don’t have a DB backup, or a recent snapshot of your fog server, you’ll need to recreate the image definitions manually. You must recreate them exactly as they were before:
- The image path must be exact and is case sensitive.
- The image OS and image type must be set exactly as well.
-
RE: LDAP - AD - User access and host joining the domain
@gjo on the host itself, you can look in the fog client log. You can also look at the “PC properties” and see it’s domain status. in Active Directory Users and Computers, you should see the new computer object. A note on this you might not be aware of, FOG will rename the system to whatever name you have set in the FOG Server for that host, it does this just before domain joining.
When I was doing a lot of imaging, we would set the hostname during Host Registration.
-
RE: FOG External Reporting
The count on working branch and dev-branch as of today is 718 fog servers.
-
RE: LDAP - AD - User access and host joining the domain
@gjo sysprepping is typically run just before image capture. This process will generalize your image to work on multiple models as well as solve some other issues with key management servers, wsus, and is the Microsoft supported way to build an image.
Re: admins, I think a fog plug-in may exist that may help. Memory is fuzzy on this.
Re: fog client, your image has to have the fog client for domain join to work. This means it must be installed on the Golden system from which you take an image.
-
RE: LDAP - AD - User access and host joining the domain
All fog users are basically admins. I’m unaware of how to figure out who’s logged in currently. There may be some details in the apache logs, not sure though.
To join computers to the domain, your image must contain the FOG Client. And, you’ll need to enter credentials into the FOG Server that have the permission to join a host to the domain. Also, your image needs to be properly sysprepped, or configured very carefully if you’re not sysprepping.
-
RE: Slack Integration
@michelbragaguimaraes Not sure if fog supports the new style of slack integration, but last I checked, slack still allows creation of the old style web hooks. Have you tried that?
-
RE: Capturing/Deploying Rocky 8.5
@ben604 Fog doesn’t support LVM at all currently, so the only way to make lvm work is with a raw image, and destination disk being identical size as the source disk. Even at that, deploying raw takes ages, super slow.
Use standard partitions instead to get the speed and resizing benefits.
Also on your swap partition failure, im sure you know this but saying anyway incase someone else doesn’t and reads this. Swap is not required. Particularly not required if you have ample ram. But, even on systems without ample ram, things still work without a swap partition.
Of course best thing is for fog to handle it right. Just offering something that might get you going.
-
RE: How to disable "password viewing" in the web UI
@sebastian-roth said in How to disable "password viewing" in the web UI:
Would be interesting to hear what others think about this.
Couple thoughts…
-
You can create an Active Directory service account with pretty limited permissions, only allowing it to join systems to the domain, and use this for FOG. This is something everyone can begin doing right now. This reduces the blast-radius should the credentials that FOG uses became exposed or compromised.
-
In the great majority of enterprise I.T. systems I work in, you can retrieve a credential “ID” (like username or access key) but cannot retrieve the credential “secret” (like a password or secret key). FOG is unique in this area, because the FOG Client needs the complete credential. Though, users should be entirely prevented from retrieving this credential… more on this in points below.
-
Merely concealing the password with the UI, someone who already has access to the FOG server could still potentially use the API to get the password. So, concealing via the UI is just obfuscation and not real security. Concealing via the UI is likely fairly easy to do and would result in less bugs to work out, but this isn’t real security.
-
Best solution in my view is to store the password within the database using reversible encryption. The encryption key should be generated by the FOG Installer, and put into
/opt/fog/.fogsettings
. The API / web components would then use one of several ways to handle encrypting and decrypting using this key. A quick internet search reveals lots of options:
- https://stackoverflow.com/questions/9262109/simplest-two-way-encryption-using-php
- https://www.educba.com/php-encryption/
- https://www.tonymarston.net/php-mysql/encryption.html
After implementing, the ability to retrieve the password in any form/nature should be secured… which leads into point 5 below.
- The transport layer between the FOG Client and FOG Server is already encrypted, but should someone call the server endpoint to get the credentials, we don’t want the password to appear plain-text within the server response. I’ve not looked into how this currently works so I’m unsure in this area. But, I’d think the FOG Client would first prove it’s identity with client-based authentication, and after this the FOG Server would provide the password to the FOG Client. Maybe it already works this way? No idea. I’m remembering @Joe-Schmitt talking about this, and how he worked with @Tom-Elliott to solve it… This was a long long time ago though, and my memory of it is super fuzzy.
-
-
RE: FOG External Reporting
Wanted to post a reply here saying the external reporting page has moved to an official home, one that belongs to FOG Project. I’m still tending to it, just the hosting location is now official. Updated links are in my signature.
-
RE: [Feedback Requested] Adding kernel info to FOG Reporting
Putting a bow-tie on this thread: This feature is complete. Link to the external reporting is in my signature, the kernels in use are beginning to show up, these figures will increase and show a bigger picture over time.
-
RE: Windows 11/Future for Us
It’s got a special section just for iPXE.
If your submission contains iPXE functionality, then additional security steps are required. Previously, Microsoft has completed an in depth security review of 2Pint’s iPXE branch. In order for new submissions with iPXE to be signed, they must complete the following steps: Pull and merge from 2Pint's commit: http://git.ipxe.org/ipxe.git/commitdiff/7428ab7 Get a security review from a verified vendor. Refer vendor to the iPXE Security Assurance Review blog post. Emphasis of the review should be on: NFS functionality being removed Wireless functionality being removed Non-UEFI loaders are not included Ensuring all known reported security problems are fixed (identified in the iPXE Security Assurance Review blog post). Share the specific commits that are made to the project, allowing Microsoft to ensure the expected changes are made.