-
Notifications
You must be signed in to change notification settings - Fork 223
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repair snapin download not working on HTTPS enabled servers #371
Comments
This was mentioned in the forums: https://forums.fogproject.org/topic/15981/snapin-cert-issues Would be great to solve this before the next release. |
Is there any workaround to fix this? And trying to modify the code to https didnt bring much difference - "As a quick fix you can edit /var/www/html/fog/lib/client/snapinclient.class.php go to line 166 or search for the string “location” to get to the right spot. Change “http” to “https” in line 166 and save." Storage nodes have https enabled and locations tagged for client to pickup snapins but failing to download snapins as per fog.log on clients |
I managed to get around this by doing the modification as described by editing line 166. I also have a proposed solution based around that but i've not fully explored if this is possible yet or not. If we can add an additional field to the nfsGroupMembers (Storage Nodes) table. If we can then ensure this field is passed through to the $StorageNode class. Again I've not looked at that yet otherwise I'd post that code too. If I get time I'll do a pull request and make the changes and test. If it works then i'll submit that as a proposed solution to this, unless @Sebastian-Roth can see any flaws in this proposed solution ? |
@bthomas1234 Thanks for posting here. I wasn't sure whether this is actually causing people trouble or if no one cares about it. Don't get me wrong. I just say this due to the fact we didn't have much talk about this in the forums (main source of input from users). We are going towards a next release and I am hoping we can get this fixed - but we don't have enough people to work on this. @Yarli Awesome you've looked into this. I appreciate your input. You are very welcome to send a pull request (towards the
Considering the situation we have here I tend to go the second route. What do you think about it? |
@Yarli Do you think you'll find some time to look into this in the next few days? |
Ive got a busy week lined up but ill see if i can pull the dev branch down at work today and have a go. My biggest issue is i need to understand the process on getting a new field added to the database. I presume thats part of the fog install script ?
Adding the UI changes and backend changes should hopefully be fairly straightforward.
… On 3 Mar 2022, at 14:53, Sebastian-Roth ***@***.***> wrote:
@Yarli Do you think you'll find some time to look into this in the next few days?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you were mentioned.
|
@Yarli Did you read my post start to end? I still don't think adding the field is the best way of fixing this issue. That way you don't need to worry about DB fields at all. |
Sorry about that, I didn't fully digest your reply as I working off my phone at the time. Looking at your suggestion of doing a detect HTTPS method, I think that'll work for most users providing it's internal only. In our setup, which is a bit weird and is certainly an edge case, we use Cloudflare and HA Proxy together to expose the HTTP part our internal FOG server ONLY, which allows us to remotely deploy snapins our end points without them needing to be on our VPN. Clients sat on our internal network still connect through our HAProxy setup, since we have the IP for our FOG DNS record pointing at our HAProxy. This allows us to still use HTTPS even though there's no HTTPS enabled on our FOG server. This also allows us to manage certificates at the proxy instead of within the FOG server and allows us to take advantage of letsencrypt free certs too, which auto renew on our HAProxy as well. That was my thinking behind having an external address field on the storage node for the snapin downloads since I suspect no one will try to image over the Internet, but would like the option to still deploy snapins etc. Happy to assist with the code on this, but wanted to explain a little about our setup and why it causes us an issue first so that we can work on a solution which hopefully works for everyone. |
@Yarli Sorry for the long delay. Thanks for the detailed explanation on your setup. I am not sure how to handle this topic. On the one hand it would be easy to fix the basic issue by trying HTTPS and then HTTP URL subsequently. On the other hand I can see why you suggest adding the DB field ( |
Ok thank you. Sorry that ive not had chance to test or develop a solution yet either. Work is fairly busy at the moment and I've not had time to setup a sandbox environment to work on this. Hoping once things die down a bit i can get onto that but that might be a while.
Feel free for anyone to push out a simple solution in the mean time and ill work on a more long term solution once i get a but more free time, if that sounds ok ?
… On 16 Apr 2022, at 17:22, Sebastian-Roth ***@***.***> wrote:
@Yarli Sorry for the long delay. Thanks for the detailed explanation on your setup. I am not sure how to handle this topic. On the one hand it would be easy to fix the basic issue by trying HTTPS and then HTTP URL subsequently. On the other hand I can see why you suggest adding the DB field (fulladdress) as it helps with your special setup just as well. With a lack of time on my end I tend to just implement the simple route for now. You are welcome to look into adding the later yourself.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
@Yarli @bthomas1234 I finally found some time to look into this again and came up with a nice solution I reckon. The URL for snapin download is only different from the default master node in case you are using the location plugin (and This works out of the box for fresh installs as we can detect if a storage node is HTTP or HTTPS when a new location definition is being added. For existing installations I suggest you first add the DB column manually:
Then update the protocol information for each existing location like this:
Or you can update all the locations if they are all on the same protocol (
|
Closing as fixed - see commit b33e4d9. |
The code added in commit d0162c8 breaks snapin download on HTTPS enabled servers and is therefore not appropriate in all cases. There is no quick fix for that as we don't have the information about a node being setup as HTTP or HTTPS in the database object for each storage node. This was missed when adding HTTPS to FOG and needs some thorough consideration.
The quick fix is to just set "https" in the code or remove those five lines that were added when trying to quickly fix the issue with snapins not downloading in locations.
The text was updated successfully, but these errors were encountered: