@Tom-Elliott said in (r7084) Login history - username searching doesn't work:
Confirmed, found, patched, fixed, tested, and pushed.
How many more words can i begin to use?
Done, Boom (mic drop)?
@Tom-Elliott said in (r7084) Login history - username searching doesn't work:
Confirmed, found, patched, fixed, tested, and pushed.
How many more words can i begin to use?
Done, Boom (mic drop)?
@Jbob
Actually I share the same concerns about disabling selinux and the firewall. But this seems to be the standard practice for installing FOG so I didn’t want to push a different agenda. I also consider that FOG appears to be targeting the smaller SMB realm from a security stance and most have FOG installed inside a properly protected network so that does mitigate some of the risks.
Just thinking out loud, if we have a list of all services used for FOG then constructing firwall rules shouldn’t be difficult at all. The application of the rules may be difficult since each linux distro handles the iptables rules a bit differently.
The selinux part will be a bit harder since FOG is writing to files all over the place. We would have to get the selinux tagging just right (we could get there if we used the permissive setting then scanned the log for the required rights. Its been a while since I did that type of activity). But from a security standpoint I like where you are going with this.
@Paul-Storic {left me hanging in chat}
Can you post an image of the host definition, please? In the host definition it should indicate what image to use.
@Wayne-Workman For the sysprep unattend.xml file it is typically in 2 or 3 spots. The reference image creator can really put it anywhere the OOBE installer can find (on the local system). But it is typically in c:\windows\sysprep or c:\windows\panther.
Today I have unattend.xml set the system name with the below sed script, it also sets the timezone, AD OU, keyboard, region, and a few other things. All by patching the the unattend.xml file with sed and a few semi intelligent scripts.
For clarity the sed script for setting the host name will work today (yesterday) before the hostinfo.php script was included in the FOG base code. But now that it can be called there are more interesting things that can be done with the unattend.xml file.
You don’t need to use an unattend.xml file with sysprep so assuming there will always be one may fail. That is why I assume the fog client updates the registry to make the change (because not everyone uses sysprep and the unattend.xml file). Along the same lines when I get back to work I need to find out why a windows 10 system is not using a predefined unattend,xml file. There has to be a registry entry somewhere that tells it where the unattend.xml file is. There is one in the image, its just not using it for some reason. If I can find out why this win10 unattend.xml file isn’t being use I may be able to feed that info to the devs to help with the name changer function. At this point I don’t want to think too much about next week.
Just a follow up, task scheduling and image capture work as expected. Issue is solved.
Actually we would like to see you generate that error message again, then view the apache error log in /var/log/httpd/error_log. The last few lines should indicate the current error. The access_log should only show use details when things go right.
@Joe-Gill Understood.
Just realize that MAK keys are churn and burn (i.e. you only get one activation per MAK key and those key’s (license) can’t be reclaimed if you dispose of the hardware. They are a one time use key). With KMS keys when you dispose of a system the KMS key returns to the license pool.
No sysprep is not required for the FOG client.
@adukes40 I’m just shooting an idea off the top of my head without actually looking into it. But if the target computers have the fog client on them, I wonder of FOG records the last check in time from the fog client. If it did you could create a report that might give clients that haven’t checked in, in the last 90, 180 or 270 days. That would tell you the systems that need to be reconciled.
Cross linking threads same issue
https://forums.fogproject.org/topic/7494/7731-image-overview-sql-select-text-is-displayed
https://forums.fogproject.org/topic/7492/host-pxe-boot-issues
https://forums.fogproject.org/topic/7493/7731-sql-error
https://forums.fogproject.org/topic/7496/7731-when-trying-to-pxe-boot-sql-command-not-found
yes after you do the svn up then cd to the bin folder and run setup again.
@Joe-Gill The actual keys used doesn’t matter for your task at hand. The systems activate the same way. The MAK vs KMS is part of your internal IT governance process (license management).
@RobertD Sorry I was going to post a link, but the URL I had saved was broken so it took me a bit longer to get the links.
https://technet.microsoft.com/en-us/mt227395.aspx
https://adsecurity.org/?p=1790
@hernani First of all I would suggest that you open a new thread since your situation may be unique with a similar end results.
While this may not be “the” solution that fixes your immediate problem, but please update to the latest release which is about 7850. You didn’t mention the FOG server OS in your post (i.e. unique ??).
There should be an install error log. Its moved around a bit during the different trunk releases. It could be in /var/log or /opt/fog/log or in /home or /home/fog. I just ran the svn update again and my install completed without error on Centos 7.
@Rusty Some systems will try to do a two way match between conical name->IP address -> conical name. This is a standard function of DNS. I’m kind of surprised that this issue (not having a reverse lookup zone) hasn’t been a problem.
What version of fog are you using? If its 1.2.0 stable its not going to work. You will need to upgrade to the 1.2.0 trunk build to get support for m.2 disks. gpt, and windows 10 that the surface uses.
With 12 systems it may be simpler to setup an MDT server to deploy with. To do this right you should have a MS Volume License key and then create your reference image (master, golden, mother, etc) with MDT. For 12 systems I would stop there. If you were going to deploy more than 50 systems per year then I would take the next step and setup a FOG server. Capture your golden image with FOG and then deploy from there. If you setup FOG and your golden image properly you can use a single golden image for all of your hardware fleet. Since you are using Dell hardware, they (Dell) made the driver collection part pretty easy for you.
Don’t let the MS VL key scare you off. You only need one per OS type you are deploying. That will give you reimaging rights that the OEM license doesn’t. Meaning if you purchase 1 VL Key for Windows 10 Pro you can deploy an unlimited number of Windows 10 Pro where Windows 10 Pro was already installed on the target hardware via a preexisting OEM license. To purchase into the MS Volume license program you need 5 points. The Windows 10 Pro VLK counts as 1 point, just add 4 other items to get to your 5 points (Like server client access licenses, you can never have too many of those and they are pretty cheap).
whelp that wasn’t it. Fixing that did some crazy things to the web gui.
@Rusty said:
Updating to SVN 4367 didn’t help with this Dell Inspiron I have here. The second laptop I have here boots into FOG menu everytime.
Not to fork this thread, but just so I can get this clear in my head.
You have two computers that are exactly alike. They are the same models, with the same bios release and the same bios settings. But one boots to the fog menu and the other hangs at the init devices?
Have you tried to reset the bios back to defaults on the one that doesn’t work, save and reboot, then make any changes necessary for your image (uefi, legacy, roms, etc.) save then pxe boot. If it still hangs. Power it off, remove the battery and charging cable. Then power everything back up. If it still hangs then I might consider the mobo has issues. There may be a way (kernel parameter) that the developers can set to tell exactly where its hanging.
Is the fog client installed and the service disabled when you run sysprep? We have found that if the fog client service is running, it starts doing it work too early in the OOBE process. Right now it is best practice to install the fog client and set the service start to disabled and then in the setupcomplete.cmd script use the sc command to set it to auto start.
If this isn’t the situation then we need to look at how you are injecting the drivers and what target system you are using to deploy to.
I don’t have an answer for you since I haven’t tried to do crazy things with the post install script but I can give you a few hints maybe they will get you started on a solution.
mount -o nolock,proto=tcp,rsize=32768,intr,noatime "$storage" /images
nfsshare images=c:\share\images -o rw sec=sys root unmapped=yes
Other random stuff
the ftp client is not in the FOS linux. Tom would have to enable the ftp client to be built when busybox was recompiled. (speaking as a user) Its not that big of a deal to turn it on, its only one line in the config file then recompile.
The same would also be true if you wanted to mount a windows share, cifs would need to be enabled in busybox.
wget and tftp (client) can be used to move files if needed. wget can also be used to get/post data to websites or make api calls.
I’m sure you already know this, but if your target computer is booted into debug mode. Give the root user a password, then you can connect to the FOS linux via putty or ssh from another computer. It helps with debugging since you can copy/paste/get screen captures much easier with putty running on windows.
Also you can build a FOS usb boot drive. So you can boot directly into the debug mode right from usb. It helps with debugging and it boots really fast.
https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image/4
Lastly I did “start” documenting some post install bits for managing a windows install in this document.
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script-under-construction