@dirtrunner21 Just a quick note for you. We already found and fixed an issue with snapin replication that exists in 1.5.5 - so if you are heavily using snapins on storage nodes I recommend you directly go to use the dev-branch
or wait for 1.5.6 (not sure when we get to release this).
Posts made by Sebastian Roth
-
RE: Fog imaging and M.2 drives
-
RE: Problem with HTTPS upgrade
@FritzBox360 Take a look at the github repo to find our current iPXE header files we use to compile the binaries - legacy BIOS and UEFI. As far as I can see both HTTPS protocoll and
cert*
commands are enabled.I might try a HTTPS enabled ubuntu install tonight to see if I can figure out what’s wrong. No promise though. Not sure if I find the time.
-
RE: Circumnavigate fog user issues
@george1421 said in Circumnavigate fog user issues:
The only thing we need to check is if you disable interactive login
Can you be more precise on this point. How do you disable interactive login? As far as I know there are half a dozen ways of doing this and none is doing it for shell/SSH and GUI at the same time.
interactions with a Master/Storage node configuration
Definitely a good point that we have to keep in mind!!!
-
RE: Circumnavigate fog user issues
@Tom-Elliott Thanks for your thoughts on this. I was looking at it from the other side. Try to entangle FOG ftp system account and web GUI account for less possibility to cause confusion.
Checking if system account already exists and has been used to logon is probably a first step towards warning the user. I am not sure but I think a general way to check last logon (terminal, GUI, SSH but not ftp logon I hope) does exist.
-
RE: Site plugin and 1.5
@Aur3l Ok, this is fixed in
dev-branch
and will be in the next release as well. The fix is fairly simple and you might want to add this on your own FOG server by hand to not have to wait for the next official release. -
RE: Locations and Snapins
@UWPVIOLATOR As I just try to pick up topics that we might have missed in the very busy Summer season I found your post again. Let’s see if we can figure this out and maybe fix it if needed.
When you set a location to image a host, even though the snapin does not exist on the locations node and the snapin definition is the only node it is assigned to
I am not sure if I get this right. Can you please be more specific to what your settings are (post pictures of web UI settings) and what exactly you are trying to do.
I get that you want to keep snapins on only one storage node. Is this because replication is causing an issue for you? We have been working on the replication code and improved it a lot. Unfortunately there is still an issue with snapins in version 1.5.5 but that’s fixed in
dev-branch
and will be in the next release.But if you still want to have snapins only on one of your nodes, should all your clients pull the snapin from that single node?!
-
RE: Circumnavigate fog user issues
@Tom-Elliott You are right, we probably still need some local system user account anyway. I started playing with it a bit and couldn’t get it to work because of PAM lib issues. Would make it all just way more complicated and error prone so we won’t go there.
As @george1421 states that he’s see several tutorials out in the wild telling users to create an account
fog
and using that to install we want to move away from that account name and make it a system account (no login allowed). Restricting shell/SSH login is fairly simple but for X login I have not found a general way to restrict login for certain users. The best I could fine is here but needs a modification of the specific login manager (gdm, kdm, xdm, lightdm, sddm, …??) PAM configuration file. This can go wrong in so many ways that I don’t think it’s even worth trying.Just changing the account name to something different without restricting login (including GUI login!) is not solving the issue but might just add to the confusion of new users.
Should we start by renaming the web UI default user name (e.g. to
admin
) and change to a auto-generated password? Do you consider this being anything worth in terms of causing less confusion? -
RE: Kernel Issue
@BrentC @fry_p Thanks heaps for reporting this. I just fixed it. You’ll find the very latest kernel at the top of the page again. Version 4.19.6 as of now.
-
RE: Problem with HTTPS upgrade
@FritzBox360 Thinking more about this I had an idea. We had a special case with Ubuntu handling redirects differently. This was about the API but I can imagine this also causing what you see here: https://github.com/FOGProject/fogproject/issues/263
On the other hand I added a fix for that which should be in version 1.5.5 already. So maybe I am on the wrong track. Still take a look at the issue because there might be valuable information and commands like
apachectl -S
to track down the issue.Please let us know if this is something we can fix in the code.
-
RE: Problem with HTTPS upgrade
@FritzBox360 The build script should re-run the installer after the binaries are compiled to install those to /tftpboot correctly. Did that happen? Any errors you got from the build script?
-
RE: Trying to capture Ubuntu 18.04.1 and I get this.
@salted_cashews said in Trying to capture Ubuntu 18.04.1 and I get this.:
Also am I understanding correctly that FoG/Partclone cannot use the “Single Disk Resizable” option on LVM partitions? We’ve had issues with LVM in the past and FoG/partclone and we ended up having to use RAW format.
Yes, that is true. We hope to get that added to FOG but there aren’t enough people to work on those kind of things as we all do this in our free time at the moment and don’t have enough of that.
-
RE: Adding an IPP printer
@sonic136 Maybe put in
iprint.domain/ipp/printername
as printer in the config. I have to admit that I don’t know much about iPrint. Just guessing here.Would you mind posting a picture of that Website where users would click to have their printer installed?
-
RE: Issues after Migrating Fog
@jherron Do you mean on the FOG server? The client error you posted as picture has nothing to do with server RAM and I highly doubt it has to do with client RAM either. How did you get to this conclusion?
-
RE: Failed to create Snapin Error
@agray Best to use the script (see the linked forum post on instructions) to change back your FOG IP to the one you have in the internet network (192.168.105.238). Then re-run the installer - hopefully running through. Now move your server back to the other network and again change its IP (now to 192.168.1.105) using the same script again.
No need for internet after the install. But if you ever need to re-run the installer… same procedure again.
-
RE: Failed to create Snapin Error
@agray said in Failed to create Snapin Error:
The ip 192.168.1.105 it the address it will be on after installed. The address it’s on while connected to the internet is 192.168.105.238
Ahhh, now I got this. Sorry I didn’t when you mentioned that between the lines in your earlier posts. So you are switching between two different networks (just for the installation part). So did you use one of our helper scripts when you initially switched from your internet subnet to the isolated network? You need to properly switch back your whole FOG server to the internet subnet IP before you can re-run the installer. I should have thought of this earlier.
Maybe it would have been all easier if I’d just tried to help you manually fix the permissions. But on the other hand I am wondering what else is messed up and so re-running the installer is still a good idea to get this all fixed up.
-
RE: Circumnavigate fog user issues
Thinking a bit more about this I am wondering if we could get rid of the local user account altogether by using vsftpd virtual users. This is untested yet and I might have missed something here. Possibly access rights could cause us trouble here but as we usually set directories to
777
(not great!!) it wouldn’t be any worse than what we have right now. -
RE: Failed to create Snapin Error
@agray The error log states that it is unable to send a request to the webserver:
--2019-01-09 09:35:45-- http://192.168.1.105//fog//maintenance/backup_db.php Connecting to 192.168.1.105:80... failed: Connection refused.
Is
192.168.1.105
your FOG server IP? Can you open that link in the browser from your client? http://192.168.1.105//fog//maintenance/backup_db.phpFrom the logs it looks like the webserver (apache2) and PHP-FPM are started properly. Please take a look at the log files mentioned in my signature and post here.
-
RE: Access Control
@NT_Tech Have you looked into using the access control plugin yet?
PLEASE re-add this functionality!
Would you be willing to help us? If it’s not coding than maybe answering those many questions coming up in the forums day by day. That would free up some time for developers then.