@Alois Sorry for my late reply, had too much work today and couldn’t respond in between. Please take a look at the apache error log to see why it fails. You find that log in /var/log/apache2/error_log
Get the last 20 lines of that file and post here.
@kasperdvdh Have you searched the forums yet. There should be numerous topics on this question.
@Alois Let’s first try to get rid of the old PHP 5.6 and make sure the FOG web UI is still running:
apt-get purge php5 php5-cli php5-common php5-curl php5-fpm php5-gd php5-json php5-mcrypt php5-mysqlnd php5-readline libapache2-mod-php5
systemctl restart php7.2-fpm.service
systemctl restart apache2.service
systemctl status php7.2-fpm.service
systemctl status apache2.service
dpkg -l | grep php5
Now try to access the web UI. If you get any error make sure you copy&paste the full command and output here so we know exactly what happened and can help you.
We have left database security as a more or less untouched topic for too long and I hope to push that forward in the next weeks.
Good practice is to set a proper DB root password as well as add a less privileged account for the actual application. If we go that route we’d need to ask the user for two distinct new passwords or generate those and display to the user. We need a hint that those should be stored in the password manager of choice or written down. But as well I feel that we should prepare a detailed wiki article on how to reset the DB root password on all distros just in case people have locked themselves out. Who’s up for that?
I intend to use mysql_secure_installation command as well.
In case people choose to let the installer generate a password I’d prefer to set a semi complex password (numbers, lower case, upper case and a couple special characters) but only 8 characters in length. That way we have a chance that people actually note it down. -> Not sure if that’s a great idea, open for discussion.
I’ll probably need to setup a whole park of VMs to test the changes before we actually release this to the public. Otherwise we’ll have a massive storm of questions in the forums and installations to fix up later on I fear. This is because we have different versions of MySQL/MariaDB in the distros and some behave differently as far as I know. We have @Wayne-Workman’s awesome installer test park running but I have a feeling that we won’t cover it all with that. We need fresh install testing but even more we need testing on upgrade installations (one with empty root password and another one with a password already set). I think I can do a fair bit of that in my VM test setup I have on my working laptop using snapshots. But I am not sure I can do it for all distros. @Moderators @Testers Anyone around who’d do the tests for one or the other distro?
Please post here if you have more ideas on this or if I have left out something important!!
Issues that we might run into as setting the password has changed several times in different versions of MySQL and MariaDB:
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY "your-password"; works, tested 25.07.19 (ref)Versions:
Creating a DB user account seems to be just as problematic across different MySQL/MariaDB versions:
CREATE USER IF NOT EXISTS or DROP USER IF EXISTS are not available before MySQL 5.7GRANT ... TO which should create a user if it doesn’t exist - doesn’t work in MySQL 8.0 though.DROP USER ''@'localhost';)mysqladmin -u root -p password 'Passw0rd' command:
@astrugatch Sorry for my late reply. Just too many other things so I set this aside for a bit…
To be clear I’m mostly speaking about the web UI right now.
Ok fine. I will work on adding that to the installer in a way that more people might use it.
But the client would be important too.
What exactly to you mean? We do state of the art encryption between fog-client and FOG server ever since the current fog-client was released (compared to the old legacy client). Anything more we need here?
The way JAMF handles the migration is that it continues to use its internal CA and distributes the new cert to the machines on check in. It keeps track of those that have received the cert and compares that to its list of enrolled machines. When all machines have received the cert there is a UI element that goes from red to green letting you know that the server can now be switched to communicate via the external CA.
Yeah this is highly advanced certificate handling that I would love to add to FOG but probably won’t find the time to do so any time soon. We are on the very edge with way too little work force working on FOG.
I’d prioritize the mentioned database password security now. Follow up topic here: https://forums.fogproject.org/topic/13267/database-security
@salted_cashews So the master installation is lost? Too bad. Think there is nothing we can do as the last image capture is incomplete and we can’t get that extracted. Hmmmmmm
@salted_cashews Strange, no idea why that is?!
@EduardoTSeoane said in Backing up user profiles/data before deploying image:
echo “/images/userbackup *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=2)”
Guess you meant:
echo "/images/userbackup *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=2)" >> /etc/exports
...
@willian As well make sure you read all this: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit
@salted_cashews I am fairly sure the image was corrupted when capturing it already. So I don’t think that deploying with the new init/kernel will help. But you might still give it a try. You never know.
@salted_cashews Ok, just finished building new inits with Zstd 1.4.0 that you can try out. I’d suggest you put the kernel and init binary alongside with the original ones instead of swapping those. This way you can test without causing any harm.
On you FOG server run (suppose you have 64 bit machines here):
sudo su -
cd /var/www/html/fog/service/ipxe
wget https://fogproject.org/kernels/Kernel.TomElliott.4.19.36.64
wget https://fogproject.org/inits/init_zstd-1.4.0.xz
chmod 666 Kernel.TomElliott.4.19.36.64 init_zstd-1.4.0.xz
Better if you do a chown ... on the files but as I don’t know your OS webserver username I thought I’d do it this way.
Now go to the FOG web UI, edit the hosts settings of the machine you capture the image from and set Host Kernel to Kernel.TomElliott.4.19.36.64 and Host Init to init_zstd-1.4.0.xz. Now schedule a capture task, let it grab the whole image and then try to deploy that new image again.
Not sure if you need to set Host Kernel and Host Init on the deploy host as well. From my point of view it’s the capture that breaks the image and deployment using the old-fashioned kernel/init might still work.
@Miodog I have to admit that I have not played with those advanced multicast settings in a while but we do have some in the web UI -> FOG Configuration -> FOG Settings -> section Multicast settings: UDPCAST STARTINGPORT and MULTICAST ADDRESS.
If those settings don’t suite your situation I am sure we can add udpcast options as needed. Just let us know.
@Tom-Elliott Are you able to replicate the issue?
@Alois Ok it’s still using PHP 5.6 in the webserver. Note that php -v is giving you different results because command line PHP is not always the same as the one used by apache.
Please post the contents of /etc/apache2/sites-enabled/001-fog.conf here. As well run the following commands and post output here:
ps ax | grep fpm
systemctl status php7.0-fpm.service
systemctl status php7.2-fpm.service
@RobertD Just a quick idea, maybe use a post-init script that copies the files to a NFS share?
@Alois I suggest we start by creating a phpinfo page to get an idea of the version currently running. Create a new file /var/ww/html/fog/info.php with the following content:
<?php
phpinfo();
?>
As well make it owned by the apache webserver user: chown www-data:www-data /var/ww/html/fog/info.php
Try open the following URL and post a picture of the output you get: http://x.x.x.x/fog/info.php
@CpServiceSPb said:
where is necessary to add/change/set up at - at Apache2 files, Php files, at MySql DB without destroying existing soft configuration.
There is no way we can give you instrcutions on how to do that without knowing your setup down to the very detail. I am very sure if I’d give you some general instructions it could break other things and we can’t give you any guaranty!!
The best way to start is by setting up FOG via the automatic installer on a different machine (fresh install without other things) to get to know FOG a little bit. From this one you can copy & paste the configs over to your other system till you get FOG working.
I am sure we can give you a hand with things that you can’t make work on your own. Just take a picture of the error and post here.
@ErwinBullen said in Imaging from Storage node fails:
Do you know a way to manual extract the image over te network to another machine/folder so i can test the network card of the server ?
Probably could test by mounting the NFS share from a different system and try to run it through partclone like this:
mkdir -p /mnt/images
mount -t nfs 192.168.100.32:/images /mnt/images
zcat /mnt/images/B-Blok-v18-v4/d1p2.img | partclone.restore --ignore_crc -O /tmp/d1p2_deployed.img -N -f 1
Make sure you have enough free space on the destination machine you are running this command from!! As well you need to have partclone installed on that system!
@Alois Are you sure the new PHP 7.2 is now used by apache? You might need to enable the module as well: phpenmod ldap ; systemctl restart apache2
Please run dpkg -l | grep php or rpm -qa | grep php and post the full output here so we can check if you have a mix of PHP versions installed now.
@Whitespire-tech Did you try to manually join the domain with exactly the same credentials? Please give it a try and see if that works.