@TaTa hmm … weird. You might try using chpasswd instead of passwd. I think that is available in RHEL … maybe by default. If it is, in functions.sh#L1262, change:
echo -e "$password\n$password" | passwd $username >>$workingdir/error_logs/fog_error_${version}.log 2>&1
to
echo -e "$username:$password" | chpasswd >>$workingdir/error_logs/fog_error_${version}.log 2>&1
Don’t have a RHEL system handy to test it with, however.
@EBCF Another route you might be able try if the dnsmasq gets problematic is to use a mapfile for the tftp server. Documentation for the format is here and I recall that you edited the xinitd service specification at /etc/xinetd.d/tftp (at least on my distribution) to get the service to use it. There is a write up on how in the workarounds for the Acer Iconia Tab w500
@TaTa The data being pulled in for the password is out of urandom, so it is not implausible that, as the log indicates, a given line may not include a digit or upper case letter. You may be able to run the installer a few more times and get a random password that conforms to the system’s password requirements. You may also be able to create a partial /opt/fog/.fogsettings with strong passwords compliant with your systems password policies. Format and settings are available in the Wiki. I haven’t tested this, but my understanding is that anything not set in .fogsettings is requested by the installer.
Edit: the setting you are likely interested in is password=.
There are two distinct statement syntaxes you are dealing with here. INSERT INTO ... VALUES... is for inserting a single row into a table. INSERT INTO .... SELECT... is for copying data from a table into another table. See INSERT - MariaDB Knowledge Base. The error you posted has both VALUES and SELECT keywords indicated. Did the query that produced that error have both keywords?
sounds suspiciously like the same hardware at issue in https://forums.fogproject.org/topic/13905/issue-with-netcard-of-dock-gen2-of-lenovo-l390
hmm, must have missed that one. Last commit I see on zazzles was for some library updates. Don’t see any specific references to service stops on 1903 in the commit notes , but could be related. Don’t see any commit notes regarding service stops on fog-service either.
Were you thinking of https://forums.fogproject.org/topic/13704/fog-service-quits-running ?
You may have to enable auditing for the fog service. That will at least tell you if Windows thinks that the service stopped. The steps for doing so are here (sorry I don’t have a more authoritative link).
sc query fogserviceshould give the exit code of the executable when run on a machine with a crashed service.
Probably not directly related to the version of FOG, but the version of FOG would influence the version of the kernel initially used for FOS which determines the supported hardware. If you haven’t updated the kernel since installation, you might want to try one of the newer ones (4.19.64 I think is the latest stable one) to see if that takes care of things. Documentation for updating the kernel is on the Wiki: Kernel Update.
No logged errors… do you see any warnings or errors in the System or Applications logs at or around the time that the last log entry happens? On a machine with a crashed service, what do sc query fogservice and sc qc fogservice return?
That isn’t an exceedingly common presentation based on a search of the forums. Could you be a little bit more specific? Which version and edition of Windows 10? Which version of FOG? Which version of the FOG Client? How was the FOG client installed (smart installer or MSI)? Was the fog client installed before the image capture or after the image deployment? If before imaging and the image was sysprepped, was the guidance in FOG_Client_with_Sysprep followed? Could you post the last 50 or so lines of fog.log from a crashed client?
@Sebastian-Roth Took a look at the service modules and the logic for the host renames is there and seems to be functional in the PR.
@dylan123
typically mariadb defaults to /var/lib/mysql/ for the data files.
It looks like your boot partition may be full. While this wouldn’t necessarily cause you issues with day to day operation, it can play havoc with apt if you have a kernel update in the queue when running updates. I have had more than several update sequences bork due to this, and depending on where it borked, I could see packages that have a number of dependencies such as mariadb being left in a non-startable state. I would suggest doing an apt autoremove to remove the unneeded kernels, but be aware you may need to manually give apt a little room in /boot by manually deleting an old kernel or two then running a apt -f install (I think) to cleanup from the dirty state. I believe Ubuntu generally keeps the current and one or two previous kernels by default.
If you want to see if this might be an issue prior to digging around, a apt upgrade should complain at you.
@brakcounty Having two network interfaces configured for the same subnet (found by performing an AND with the interface’s IP address and subnet mask) but not having those interfaces actually connected to a common network is going to cause problems. When sending traffic to an IP address, a routing table is consulted to direct the traffic to the appropriate interface. If there is no differentiation between the interfaces, then you are depending on the order in which the routing table was built to determine to which interface outbound traffic is sent. As there are a number of things that could trigger a change to that table, such as media disconnects, reboots, and dhcp lease expirations (if your fog server is not configured to use static addresses), access to the machine through both interfaces will be unpredictable. You should change your network configuration so that the interfaces are in different networks.
@scottedwards54 If the installer is contained entirely in the one file, you could implement it as either a regular snap-in or a snap-in pack. The pack approach would be useful if files other than just the executable were involved, such as maybe a batch script in case the fog service couldn’t keep track of the installer process where the start invocation would for some reason or you wanted to do other things at the time of install. Altering the script to include setting up authentication to the smb share with net use would also be a solution, but could get substantially more involved depending on your environment, share configuration, and which editions of windows your clients are running.
I don’t believe that process has changed since 1.3 (someone please correct me if I am off on this), but the Wiki article for changing a server IP Address points to making those changes in /opt/fog/.fogsettings and re-running the installer to take care of the FOG configuration. Changing the IP address for the OS will be dependent on distribution. Which flavor are you running?
I don’t think the copy command can find the file as specified. I have yet to come across any SMB path specifications that include the double quote character as part of the path. maybe you are intending to do something along the lines of :
copy /z /y "\\\[server]\public\AV Install\setup.exe" c:\AV
edit: forgot the restartable flag, although I don’t know how useful it is in this context.
edit: forums don’t like the double backslash
I have also found it can be helpful to dump the output of a file to a log of some sort during testing, either in the snapin script or by modifying the snapin arguments.
I have been running FOG without too much issue on both Ubuntu 14.04 and 16.04. I have yet to try upgrading to 18.04, but there do appear to have been some issues with installation of the most recent version (1.5.7) on the forums. This is actually generally expected when new major versions are released and it does take some time to work out the kinks for each new distribution. General guidance from the installation wiki is to use the distribution with which you are most comfortable as some tinkering may be required (as is the case for most open source projects) depending on your environment and use case. Centos has been tested and works … see this post
@Sebastian-Roth Added in the launchctl invocation for org.freeghost.daemon.plist at the end of Install() and things now appear to be behaving per the Wiki; the system daemon and user agent start automatically on reboot. It should be noted that the launchctl invocation both starts the system daemon and registers it for restart, but the user service won’t appear until reboot. Probably should have someone look to style and location of the logic. It may make sense to add something to the IInstall interface in case other environmental issues need to be addressed for other OSs later. Likely should add something to capture the relevant environment elements that trigger the relaunch for troubleshooting, particularly to capture the state during automated installs, but the Log class wasn’t cooperating with me. Otherwise, it should be ready for some sort of functional review and testing.
How would you like to proceed?
@Sebastian-Roth The Middleware::Response Invalid host was expected; the host wasn’t registered at the time of the initial query. It is now and producing logs like:
9/17/2019 10:29 AM Middleware::Communication URL: http://10.10.25.15/fog/management/index.php?sub=requestClientInfo&configure&newService&json
9/17/2019 10:29 AM Middleware::Response Success
9/17/2019 10:29 AM Middleware::Communication URL: http://10.10.25.15/fog/management/index.php?sub=requestClientInfo&mac=38:C9:86:4F:EE:1E|28:F0:76:49:AD:70|0A:F0:76:49:AD:70|26:EA:E7:94:F6:3A|1A:00:01:E3:00:70|1A:00:01:E3:00:71|1A:00:01:E3:00:70&newService&json
9/17/2019 10:29 AM Middleware::Authentication Waiting for authentication timeout to pass
9/17/2019 10:29 AM Middleware::Communication Download: http://10.10.25.15/fog/management/other/ssl/srvpublic.crt
9/17/2019 10:29 AM Data::RSA FOG Server CA cert found
9/17/2019 10:29 AM Middleware::Authentication Cert OK
9/17/2019 10:29 AM Middleware::Authentication No token found at /opt/fog-service/token.dat, this is expected if the client has not authenticated before
9/17/2019 10:29 AM Middleware::Authentication ERROR: Could not get security token
9/17/2019 10:29 AM Middleware::Authentication ERROR: Could not find file "/opt/fog-service/token.dat"
9/17/2019 10:29 AM Middleware::Communication POST URL: http://10.10.25.15/fog/management/index.php?sub=requestClientInfo&authorize&newService
9/17/2019 10:29 AM Middleware::Response Success
9/17/2019 10:29 AM Middleware::Authentication Authenticated
9/17/2019 10:29 AM Middleware::Communication URL: http://10.10.25.15/fog/management/index.php?sub=requestClientInfo&mac=38:C9:86:4F:EE:1E|28:F0:76:49:AD:70|0A:F0:76:49:AD:70|26:EA:E7:94:F6:3A|1A:00:01:E3:00:70|1A:00:01:E3:00:71|1A:00:01:E3:00:70&newService&json
9/17/2019 10:29 AM Middleware::Response Success
9/17/2019 10:29 AM Middleware::Communication URL: http://10.10.25.15/fog/service/getversion.php?clientver&newService&json
9/17/2019 10:29 AM Middleware::Communication URL: http://10.10.25.15/fog/service/getversion.php?newService&json
9/17/2019 10:29 AM Service Creating user agent cache
9/17/2019 10:29 AM Middleware::Response Invalid time
9/17/2019 10:29 AM Middleware::Response No Printers
9/17/2019 10:29 AM Middleware::Response Module is disabled globally on the FOG server
Fair warning: some of this is likely just me getting familiar with the code base… correct me as necessary.
That code segment kicks off the script that starts fogservice.exe after installation, but it is only executed when the OS is linux (UniversalInstaller.cs#L308). But if fogservice.exe were to start for macOS, I don’t see any place in fogservice that registers org.freeghost.daemon.plist as something to be started automatically by the operating system.
The (limited) documentation (Apple Terminal Users Guide, launchctl man page), a blog post, and more misc. google-foo seems to show a consensus that services are loaded via launchctl. I do see that the expected calls to launchctl exist in UpdateHelper (using the legacy load/unload invocations), but I am having some difficulty tracing the execution back through Zazzles updater abstraction to there. On the surface it appears to rely on the existence of SmartInstaller.exe, so I would assume (possibly incorrectly) that the update code is only invoked when an update is called for by the fog server. In this case, the call to launchctl never happens, the services (system daemon and user agent) are never registered, and the daemon doesn’t start on reboot. That would be consistent with an empty fog.log as I found.
This is of course assuming there isn’t another means of registering the daemons in use, in which case It would be helpful to know what the intended implementation was so I can take a look at how it’s breaking. Otherwise, I will likely try adding in the launchctl invocations to Install() when I have some time to test again.
@Sebastian-Roth
/opt/fog-service/fog.log was an empty file after rebooting the machine. Manually launching the service (sudo /opt/fog-service/control.sh start) produces the familiar logs but complains about FOG Server CA NOT found in keystore:
9/17/2019 10:09 AM Main Overriding exception handling
9/17/2019 10:09 AM Main Bootstrapping Zazzles
9/17/2019 10:09 AM Controller Initialize
9/17/2019 10:09 AM Controller Start
9/17/2019 10:09 AM Service Starting service
9/17/2019 10:09 AM Bus Became bus server
9/17/2019 10:09 AM Bus Emmiting message on channel: Status
9/17/2019 10:09 AM Service Invoking early JIT compilation on needed binaries
------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
9/17/2019 10:09 AM Client-Info Version: 0.11.16
9/17/2019 10:09 AM Client-Info OS: Mac
9/17/2019 10:09 AM Middleware::Authentication Waiting for authentication timeout to pass
9/17/2019 10:09 AM Middleware::Communication Download: http://10.10.25.15/fog/management/other/ssl/srvpublic.crt
9/17/2019 10:09 AM Data::RSA ERROR: Unable to retrieve FOG Server CA
9/17/2019 10:09 AM Data::RSA ERROR: FOG Server CA NOT found in keystore
9/17/2019 10:09 AM Middleware::Authentication ERROR: Could not authenticate
9/17/2019 10:09 AM Middleware::Authentication ERROR: Value cannot be null.
Parameter name: authority
Manually relaunching the service under the root user context (sudo -i /opt/fog-service/control.sh start) shows it starting to communicate normally:
------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
9/17/2019 10:15 AM Client-Info Version: 0.11.16
9/17/2019 10:15 AM Client-Info OS: Mac
9/17/2019 10:15 AM Middleware::Authentication Waiting for authentication timeout to pass
9/17/2019 10:17 AM Controller Stop
9/17/2019 10:17 AM Service Stop requested
9/17/2019 10:17 AM Middleware::Authentication ERROR: Could not authenticate
9/17/2019 10:17 AM Middleware::Authentication ERROR: Thread was being aborted.
9/17/2019 10:17 AM Bus Emmiting message on channel: Status
9/17/2019 10:17 AM Main Overriding exception handling
9/17/2019 10:17 AM Main Bootstrapping Zazzles
9/17/2019 10:17 AM Controller Initialize
9/17/2019 10:17 AM Controller Start
9/17/2019 10:17 AM Service Starting service
9/17/2019 10:17 AM Bus Became bus server
9/17/2019 10:17 AM Bus Emmiting message on channel: Status
9/17/2019 10:17 AM Service Invoking early JIT compilation on needed binaries
------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
9/17/2019 10:17 AM Client-Info Version: 0.11.16
9/17/2019 10:17 AM Client-Info OS: Mac
9/17/2019 10:17 AM Middleware::Authentication Waiting for authentication timeout to pass
9/17/2019 10:17 AM Middleware::Communication Download: http://10.10.25.15/fog/management/other/ssl/srvpublic.crt
9/17/2019 10:17 AM Data::RSA FOG Server CA cert found
9/17/2019 10:17 AM Middleware::Authentication Cert OK
9/17/2019 10:17 AM Middleware::Authentication No token found at /opt/fog-service/token.dat, this is expected if the client has not authenticated before
9/17/2019 10:17 AM Middleware::Authentication ERROR: Could not get security token
9/17/2019 10:17 AM Middleware::Authentication ERROR: Could not find file "/opt/fog-service/token.dat"
9/17/2019 10:17 AM Middleware::Communication POST URL: http://fogserver/fog/management/index.php?sub=requestClientInfo&authorize&newService
9/17/2019 10:17 AM Middleware::Response Invalid host
9/17/2019 10:17 AM Middleware::Communication URL: http://fogserver/fog/service/register.php?hostname=ASCAS-TestImac.local&mac=38:C9:86:4F:EE:1E|28:F0:76:49:AD:70|0A:F0:76:49:AD:70|26:EA:E7:94:F6:3A|1A:00:01:E3:00:70|1A:00:01:E3:00:71|1A:00:01:E3:00:70&newService&json
So, it looks like the service works, but the daemon and user agent aren’t loaded correctly. I actually don’t see where those service loads happen during install. I would expect they would be handled in Install() in MacInstall.cs as Uninstall() calls unload for the services, but the only reference I see to the load call are in StartService() in MacUpdate.cs and the OnUpdate event handler in FogUserService.cs.