@gchartrandCRL Might I suggest you try out the RC-6 of 1.4.0? 1.3.5 had a lot going for it in regards to disk resizing but it still wasn’t quite right. 1.4.0-RC-1 addressed a couple more issues, and I think 1.4.0-RC-3 was intended to fix the alignment issues that could happen on occasion. Mind updating to the RC and trying to capture the image? I know it likely means you need to rebuild the image, but it should work better.
Also, when building your image, please make sure to disable fast boot.
@Tom-Elliott said in Problem with deployment : error checking mounting file system:
sudo touch /meti/images/.mntcheck /meti/images/dev/.mntcheck
sudo chmod -R 777 /meti/images
sudo chown -R fog:root /meti/images
sudo mkdir -p /meti/images/dev/
sudo touch /meti/images/.mntcheck /meti/images/dev/.mntcheck
sudo chmod -R 777 /meti/images
sudo chown -R fog:root /meti/images
@bmick10 Please rerun the installer. This has been a common problem overnight apparently.
did you run the mysql command as root?
Have you tried re-running the fog installer?
What’s in your apache error logs? (Basing this on “nothing comes up”)
What version of FOG are you running?
If you reran the installer, this problem should’ve failed to complete installing.
@ENorum THat’s a part of the migration itself.
The definition’s are not automatically populated. What this means is moving an image from one server to another without a definition already set just uses disk space.
@Wayne-Workman Can you explain exactly how you came to this determination? You replaced zstdmt with pigz in the appropriate spots?
I’ve not seen any problems with Zstd AS the compression medium. The only time, from my experience, that I’ve seen this problem is if the image was originally captured (as is the case any time before 1.3.5-RC-9) in PIGZ format.
I ask because, this problem is not seeming to be all scenarios and Zstd is supposed to be able to decompress (and it does succeed even in this case) Gzip files.
I am asking for specificity because I can easily adjust the code to use pigz if the format is originally pigz captured.
@Seydoo A “hash was the same no matter the snapin” leads me to think it was failing to get the file. When this would fail, it would cause the file to be nulled, so the hash being returned was that of a null value. (for all cases, which is why it was the same).
Init’s are rebuilt and in the binaries1.4.0-RC-9.3.zip file.
You can try with:
wget -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz
wget -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xzOr more accurately, it’s like calling a number that’s been removed from use. You could re-apply it relatively easily, but if you’re shying away from keeping it available for whatever reason, NO ONE will be able to call it to begin with.
The way fog works uses FTP to do the image transfer and what not, so just asking for a workaround for a system that’s heavily in place already seems a bit out of scope for what we actually DO.
You can figure out how to do this if you’d like, but this isn’t (at least doesn’t sound to me) like something people have done before. – With FOG
Is there a particular reason you need to use a Windows Share as the storage location? (I understand the why, but it won’t work as I think you’re imagining it will).
@Quazz Windows 10.
The Virtual Host is VMWare Workstation.
The VMWare VM is Running, now, Ubuntu 16.04 (or should be last I talked.)
The problem is something specific to NFS based on my troubleshooting.
To test, I actually simply disabled the nfs service and tested, Immediately the System fails to connect. Other virtual machines have no problem communicating, just physical machines seem to not be able to get through.
We’ve turned off the firewall on the machine entirely so Windows is not blocking the connections. The network was tested with Host-only->Bridged, and NAT. Bridged is the appropriate thing to use, but while we were testing it was worth the extra effort.
I suspect the problem is something with return to the physical machine rather than a problem with the VM, Windows OS or not. There is a switch that the devices communicate through and I’m suspecting it’s this causing our problems.
@Andre do you have a “dummy” switch you could place between the FOG Server nic and the Main machine? You’d likely want to change the VM Nic to use NAT and make sure it’s setting the same machine to the same IP as your fog server is expecting. Essentially I’d like to remove the current switch from the scene almost altogether as I suspect the switch is preventing back communication.
@killerm What ended up being the problem and how did you solve it?
I don’t know what was wrong, but you could simply reclone the repository.
(It seems to me something was not applied properly).
Maybe you can try:
git reset --hard
git checkout master
git pull
git checkout dev-branch
git pull
Please open terminal.
Run:
sudo mysql -u root (If you have a password for your root user you will need: sudo mysql -u root -p)
Once in mysql shell run:
use fog;
update tasks set taskStateID=4 where taskStateID in (0,1,2,3);
You should have no more “active” tasks.
I have it currently replacing anything that’s not _ A-z 0-9. This is more of a safety net than a requirement. I can add it back in though. I’ll add back in the capability. It will replace anything in “regex” form of: /[^\w+\/\.-]/g This will be available for 1.4.0.
Quick and dirty I think. Please feel free to modify/suggest changes as you can/see fit.
The FOG LDAP plugin is a simplistic means to authenticate using a Domain and/or LDAP System.
Its uses and configuration may very depending on the organization.
When creating or editing a current LDAP entry the following items and data expected are:
LDAP Connection Name (Required)
This is just a basic name to give for record keeping.
LDAP Server Description. (Optional)
This is just a basic definition for record keeping.
LDAP Server Address (Required)
This is the address of your LDAP Server. This, most likely, will be the domain name that it’s
handling. (eg. somedomain.local, somedomain)
LDAP Server Port (Required - Defaults to 389)
This is the port to connect. Only two are viable currently 389 (Default ldap port)
and 636 (LDAP Secure). Most likely, however, 389 will be what you need. 636 would require
a certificate which FOG’s implementation of LDAP is not currently available.
Search Base DN (Required) (Distinguished Name)
This is the base dn to search the directory tree within. This could be where you want to
start searching for users.
Group Search DN (Optional)
This is where the Domain contains group names and where you want to search within for groups.
Admin Group (Optional) (If blank Mobile must be set.)
This is a list of Groups that will tell which users will be considered “admins”.
This can be comma separated. This is not the DN to the group name, this is just the name
of group. (e.g. fogadmins, not OU=fogadmins,DC=example,DC=com).
Mobile Group (Optional) (If blank Admin must be set.)
This is a list of Groups that will tell which users will be considered “mobile”.
This can be comma separated. This is not the DN to the group name, this is just the name
of group. (e.g. fogmobile, not OU=fogmobile,DC=example,DC=com).
Initial Template
The template to apply for the attributes to search for. (e.g. samAccountName and member).
This is not stored to the db, just meant as a means to automatically populate the
attribute fields with the common elements used for the LDAP Type being selected.
The templates are:
User Name attribute (Required)
The attribute to filter the username with.
Group member attribute (Required)
The attribute to filter the group member information with.
Search Scope
The Scope to perform your LDAP lookup.
Bind DN (Optional)
The DN needed to search the domain.
Bind Password (Optional) (If Bind DN is set, this will be required)
The password for the bind dn to authenticate.
@george1421 I think something is weird
For clarity.
An nfs share cannot be reshared.
Think of it like: you have two car keys to drive a car.
One person takes one key and drives the car. You may take your other key, but if another key is in the ignition your key won’t matter. Or if the car is in use your key won’t matter.
@reprised Glad you have fixed it, but the reason we asked you to update is because 1.4.0 will be released soon and the problem we believe is addressed. Knowing if things are working properly before release is more important.
I encountered another user having a similar problem with this yesterday. It happened to be the proxy/filter was causing the binary data not to be stored properly. The binaries file would download, but the data was not available and would cause a failure. @Tim-Reynolds Please see if you have a content filter that may be causing problems.