@jeremyvdv said in Mount NFS:
so i change the fstab to have a mount point to this directory
@jeremyvdv Changing the fstab on your FOG server to mount an NFS share as your /images folder is the situation @Quazz is describing as not permitted; each machine must have it’s own connection to the NFS share.
Edit: If you wish to capture images directly to the NAS, there is a rough guide to setting up a NAS as a storage node for FOG in the Wiki.
@jdriz
Have you attempted to manually wake the machines? It isn’t installed as part of FOG, but wakeonlan should be available for installation through your distribution’s package management system. I believe the syntax is wakeonlan <mac address>
What model machines are the clients? Some manufacturers (notably Dell) have other settings besides wake on lan that need to change for wake on lan to function correctly.
Edit: You may need to add the -i <ip address> argument if your default route is to eth1. The IP address in this case could be 10.100.20.255 (directed broadcast address for your client network).
Are the nics in the server on different networks (i.e. is the subnet mask more than 16 bits / 255.255.0.0)?
In which network are your clients?
Do the clients actually wake up when the task is scheduled?
Keep in mind that wakeonlan sends its packets to the broadcast address (255.255.255.255). Traffic to the broadcast address is not routed beyond the network in which it is generated.
/etc/hosts is used for storing local hostname to IP address mappings. It is unlikely to be involved in the wakeonlan process.
Some initial information will be helpful:
Which version of FOG?
Which kernel is being used for FOS (file /var/www/fog/service/ipxe/bzImage)?
What is the model of the machine that stops after pulling init.xz?
@mikeakin44 and what happens if you make the same boot order change on your reference machine?
If you would please, answer the following:
Which boot method are you using (Legacy BIOS or UEFI)?
What is the boot order, or boot orders if there are separate sequences for normal, automatic, and error?
What are the settings for the image type and the partition targeted?
What is the content of the d*.partitions files in the folder for the acquired image?
Was the image acquired and restored to the same machine? If not, do the boot types on the two machines match (UEFI / Legacy)?
What are your boot orders (yes, there may be several) set to?
Do you happen to have any other storage media connected to the machine you are sending the image to?
We actually have a related issue in some of our student labs with a configuration management product (Deep Freeze) that discards changes to the filesystem; the machines in question lose their trust relationship whenever they are rebooted. I’ve mulled the issue over a bit and have some testing slated to attempt using junctions to offload the token storage location to a non-managed volume. I think the same approach might be viable for a dual-boot system through the use of junctions and symbolic links to tie the file locations containing the token in each operating system to a 3rd commonly readable file system. Thoroughly untested, mind you, but should be a viable workaround.
I would not say there is no way, but depending on what your goals are, you may not be able to do so directly from that context. You may want to look at alternative setting mechanisms, such as setx, for setting System environment variables and user variables for the SYSTEM account. If you are attempting to set environment variables for end user accounts, you could look at setting that during login as a scheduled task or with a logon script.
SYSTEM should generally have full control over the HKLM\SOFTWARE hive, but there isn’t anything preventing things from changing the permissions of keys. You may want to verify the permissions for the key you are attempting to modify haven’t been set by the application you are attempting to manage.
It may be helpful to have an interactive environment for testing. I have found Sysinternals PSExec to be very useful for setting that up (psexec.exe -s -i <environment binary>).
@ayashkam
The SYSTEM account is generally able to access network resources, but you can not assume any credentials would be correctly impersonated. Is there a proxy in the mix?
How are you attempting to set these variables and in which context are you attempting to set them? You are likely going to be constrained to setting them at the machine level.
HKLM should be accessible. How are you attempting to set the values.
If it doesn’t come out in the hows, some basic additional information:
Which scripting environment are you using?
Which version(s) of (I assume) Windows are these being executed against?
@TaTa You mentioned early on that this machine is managed by an external entity. You may want to check with them to see if they are using some tool to enforce a desired state, such as Ansible, Puppet, or Chef.
@TaTa said in FOG installation errors:
But Storage node and creating new image still don’t work.
What message(s) appear when accessing the storage node or attempting to create a new image? Can you post the Apache error (/var/log/httpd/error_log), php error (/var/log/php*-fpm.log), and mysql error logs (/var/log/mysql/error)? It may also be helpful to verify your error log verbosity is at least 2 in your my.cnf.
@TaTa What is the result of select vvalue from fog.schemaVersion;?
@TaTa each username-host pairing is considered a distinct user, so there is no need to drop fogstorage@localhost before adding fogstorage@‘%’. That being said, if the user fogstorage@‘%’ has existed in the MySQL instance at any time since either A) the MySQL service has been restarted or B) the privilege table has been reloaded, the user you are attempting to add likely still exists in memory which would result in error 1396 if you attempt to add the same user again. Try restarting the mysql service or performing a flush privileges; in mysql and try again.
@TaTa What indicates to you that the wildcard is not allowed? See MySQL’s documentation on creating accounts. It would be helpful to see both the error message encountered as well as the output of select user,host from mysql.user;
@TaTa The % in the host attribute is the mysql wildcard. This indicates that the user account is allowed to login from any machine. Changing this to localhost means you can only log in from a connection mysql / mariadb explicitly identifies as localhost. Unfortunately, localhost isn’t the only possible identifier possible for a local connection, for example it could use 127.0.0.1, so it is possible that this configuration would deny connections initiated on the same machine, which would result in that storage node warning.
Newly installed and updated Ubuntu 18.04 box throws a couple of error messages during fog installation
From foginstall.log:
* Setting up and starting TFTP Server.........................Too few arguments.
Too few arguments.
OK
* Setting up and starting VSFTP Server........................OK
Results in TFTP daemon not restarted after configuration change. Running configuration points to directory /var/lib/tftpboot. Configuration is corrected on service or server restart.
Traced to functions.sh#L458-L459
systemctl is-active --quiet && systemctl stop tftpd-hpa >>$workingdir/error_logs/fog_error_${version}.log 2>&1 || true
systemctl is-active --quiet && true || systemctl start tftpd-hpa >>$workingdir/error_logs/fog_error_${version}.log 2>&1
Probably should be:
systemctl is-active --quiet tftpd-hpa && systemctl stop tftpd-hpa >>$workingdir/error_logs/fog_error_${version}.log 2>&1 || true
systemctl is-active --quiet tftpd-hpa && true || systemctl start tftpd-hpa >>$workingdir/error_logs/fog_error_${version}.log 2>&1
You may also have a fog_schema_update_error.log someplace. It looks like schemaupdaterpage.page.php drops that if it encounters an error. I’m not entirely sure where it would drop it, however.
If the machine in question only has one network interface, you may need to be aware of the network addressing of both the routed and isolated networks. There are a number of places where the IP address for interface used for imaging the client machines is referenced and if that address changes between installation and use, you may need to re-run the installer to update those references… Instructions are available in the wiki at Change FOG Server IP Address.
@TaTa I think your server config file should be at /etc/my.cnf.d/server.cnf.
Can you post the output of systemctl status mysqld.service and journalctl -xe?
@TaTa Actually, what is the result of getenforce?
Was searching around a bit and apparently, SELinux can cause some strange behavior…
https://forums.fogproject.org/topic/6926/setting-up-fog-password-fails-on-clean-new-centos-7-install
Instructions for setting SELinux to permissive or disabled can be found at https://wiki.fogproject.org/wiki/index.php?title=CentOS_7