Best posts made by Wayne Workman

@JJ-Fullmer since the script deletes drivers, would you be interested in sharing how you deploy drivers?

@andyroo54 said in new fog appliance:

I honestly think clonezilla shouldn’t really exist… why use that when you could use fog?

Yeah, I cringed at that statement too. Clonezilla definitely has it’s place in the cloning world. For instance, it’s the most simple way to take an image of a fog server! And also, Clonezilla is for people that don’t have a super-fast network and don’t have an extra computer laying around to be used as a server… or for a network where PXE booting doesn’t work for some reason or another. There are many reasons why Clonezilla is absolutely valid and why it’s needed.

You can’t compare FOG to Clonezilla. They both image, but it’s like comparing a 1/2 inch short-well socket to a 1/2 inch deep-well socket. Both sockets will turn a 1/2 inch bolt but each one is superior in different circumstances and spots.

This tutorial utilizes the new FOG Client, which is capable of executing powershell scripts.

At work, we’ve been talking about how to reset the local ‘tech’ password en-mass should we ever need to, in case the account password is compromised.

I’ve found some powershell that can do this, and I’ve used it via FOG Snapins to successfully change a local Windows account’s password. This can be done on one computer or thousands. Confirmed working on Windows 10.

The below is a powershell script (with a .ps1 file extension) that resets the password of a local account called tech to MySuperAmazingPassword as an example.

$comp=hostname
$tech=[adsi]("WinNT://" + $comp + "/tech, user")
$tech.psbase.invoke("SetPassword", "MySuperAmazingPassword")

This can be made into a FOG Snapin using the PowerShell template, and just uploading the file. Here is a screenshot of the completed snapin:

@andyroo54

Ubuntu changes a lot. Even between updates of the same version, and I need two hands to count how many times Tom has ranted about Ubuntu making a change that breaks something in FOG. Red Hat and it’s variants have a winning track record on this battle ground.

Plus, CentOS is often cited on the net as the best linux platform for servers. I’d rather go with Debian than Ubuntu, but my top choice would be CentOS. There is also a whole lot of documentation for CentOS, and Red Hat documentation is compatible with CentOS as well, since CentOS is built from Red Hat Enterprise Linux source code (with minor changes).

GUI - yes. Doesn’t matter which one to me. Probably whichever one has the best external-media features. In CentOS 7, “Server with GUI” gives you a basic GUI that is pretty solid.

FOG Version - 1.3.0. We can play around with a Trunk VM until then.

Addressing - DHCP. If your setting up a virtual server for production, you probably already have a legit DHCP server that you have access to as well.

We can include a tool to change the IP address should they want to use something different. I have such a tool already written for CentOS 7 that could be modified easily to just be a run-once thing.

2 cores - this would affect the architecture of the OS, if we don’t have at least 2, then the OS isn’t 64 bit - and I don’t think that CentOS 7 even supports computers with 1 core anymore.

One NIC. In my opinion, a multi-NIC fog server is beyond the scope of a pre-built noob-VM.

Hypervisor platform - as many as we can. Once we have one built, it shouldn’t be hard to move the data to another. And even if we couldn’t, I’d be fine with building the same setup on many hypervisor platforms.

Where to host? Here and anywhere else that will host it. I’d be willing to be a backup mirror. Others might volunteer as well. This could be a way to “Give back”, hosting the VMs. We’d need SHA1 and MD5 and other checksums for people to verify the VM is legit.

My 2 cents.

Everyone, thank @george1421 for his awesome work with dnsmasq and FOG.

I’ve compiled a new dnsmasq article using mostly George’s work, it’s here:
https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq

Just spoke with @Tom-Elliott

He now takes the IP that iPXE gets from DHCP, and passes it as a kernel argument - and the latest FOG kernel 4.7.1 accepts this IP and uses it. So if the IP is already configured in the kernel, UDHCPC doesn’t need to get a new IP - but it still gets DNS addresses. If for whatever reason the kernel doesn’t get passed an IP, UDHCPC will request one. It operates as a sort of failsafe now.

This also means the latest kernel should work with 1.2.0 in theory - no promises.

Also - This change allows FOG to work with PortFast turned OFF. Yes, you heard me right. Tested working at work.

@Developers @Moderators @Developers

Things you should think about. These things are often overlooked just because people don’t know. Well, I’m here to tell you so you know.

1. Backing up your database - or at least your hosts - might be very important to you.
2. Copying your old images - might be very important to you.
3. Maintaining control of existing deployed FOG Clients - might be very important to you.
4. Do not use dynamic disks in your hypervisor.

---

If the web interface is working - you can export just hosts by going to Host Management -> Export. You can also export the entire database by going to FOG Configuration -> Configuration Save -> Export. You’d import these things in the same area.

If the web interface is not working, you can export the database via CLI. If there is no password for the FOG database, you would export as:
mysqldump fog > fogdb.sql

If the database is password protected:
mysqldump fog -p > fogdb.sql
Then provide the password when prompted.

And then move this file off of the server to somewhere else via a number of ways, the most easy being SCP to another linux box - the “Other” linux box can be any of your storage nodes or other fog servers or linux boxes. This is just a db backup, it’s just a file. SCP syntax is:

scp user@source user@destination

If the source or destination is the local server you’re working on, leave off the user part.

For example to send:
scp fogdb.sql root@10.2.1.11:/root

To retrieve:
scp root@10.2.1.11:/root/fogdb.sql fogdb.sql

To import the db via CLI:
mysql < fogdb.sql

If password protected:
mysql -p < fogdb.sql

You can find additional details and help here:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL

There’s a number of ways to copy images. Many ways are listed here:
https://wiki.fogproject.org/wiki/index.php?title=Migrate_images_manually
Don’t forget to consider image definitions, this is included in the above article.

Fog is secure. Existing FOG Clients absolutely will not accept a new fog server if it doesn’t authenticate as the genuine server the FOG Client knew when it was originally installed on said machine/image. Without getting too technical, know that this authentication cannot be faked. If this happens, there is no dramatic impact other than the existing FOG Client installations being of no use.

However - you can move the old fog server’s certificates to the new server. This is easy to do if you have access to the old fog server. This allows you to maintain control of all the existing fog clients - because the FOG Server will authenticate as genuine because it’s using the correct certificates. Steps are here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server

October 23rd, 2016
FOG Version: 1.3.0 RC-15

• Arch Linux 2016.10.01 fully updated - installs without issue.
• Debian 8 fully updated - installs without issue.
• Fedora 24 fully updated - installs without issue per wiki instructions.
• Ubuntu 16 fully updated - installs without issue.
• CentOS 7 fully updated - installs without issue per wiki instructions

I’ve cleaned up the Ubuntu 16 server article a little bit, and placed a video I’ve had about partitioning it for safe use with FOG. It’s still not complete yet.

https://wiki.fogproject.org/wiki/index.php?title=Ubuntu_16.04_Server

I can do the English translations, Joe.

@itsl3v1s FOG now has what’s called postinitscripts which run before the imaging process. You can script mounting the local drives one at a time and looking for /mnt/users and copy that off to somewhere.

This of course wouldn’t work for encrypted files or bitlocker’d systems, but neither would any other method either.

I think so, but only for bug fixes and updated ipxe files as bug fixes are made, no more new features and no more behavior changes.

The focus is shifting to the 2.0 rewrite, which Joe has been taking the lead on.

@cheisler8504 You can probably set the multijoin boot entry to be the default item, and modify the ipxe script for this item to set a valid user/pass. See the picture below.

This is inside of FOG Configuration -> Ipxe menu item settings.

Soon, the fog installer dashboard (see my signature) will have streak counts for each item. There will be a current success streak and a record success streak.

I’ve been wanting to do this for a while, I think it’ll be fun to watch the counts stack up. I’m monitoring the files for a couple days to be sure everything is working right before I put the values into the tables.

All, check this out, I appreciate feedback:
https://wiki.fogproject.org/wiki/index.php?title=Getting_FOG

Wanted to post a quick status of the testing’s streaks. You can see them in the link in my signature.

Currently, we have 4 Linux distributions that are neck & neck for the title of ultimate stability on the FOG Master branch.

We have a current streak of 40 for these Linux distributions:

• CentOS 7
• Debian 8
• Debian 9
• Ubuntu 16

We will see which Linux distribution pulls ahead in the long haul these coming months (and years). The race is ON!

https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

@eroldin at any rate, we greatly appreciate you trying to help out - we need more people helping out. If you find anything else, please do raise a new thread about it here.

The basic answer is to delay the startup of FOG services by like 30 seconds.

Just was wondering - I remember something about getting rid of these binaries because whatever problem the Surface Pros had with later versions was fixed. Maybe my memory is wrong, idk. But - if they are removed, I guess we need to update the default ISC-DHCP configuration to not use the 7156 binaries anymore.