Agree with all Tom’s points, NFS is not a simple protocol to harden.
What I recommend is VLANing your FOG network so it is manually exposed via your switch configs. Does require managed switching, but will accomplish the task.
Agree with all Tom’s points, NFS is not a simple protocol to harden.
What I recommend is VLANing your FOG network so it is manually exposed via your switch configs. Does require managed switching, but will accomplish the task.
@coconutdog The install script needs to be run from the installation directory.
Make sure you cd to the dir with the install script before running.
@kermit1991 Sounds like a user context issue. I’m not sure on what the snap in engine runs as but I would assume SYSTEM. If this is the case your message would appear on SYSTEM’s desktop, which doesn’t exist.
You can figure out who the snap in is running as by looking in Task Manager or testing e.g. ‘whoami > %temp%\snapinuser.txt’ – this will print the username running the script.
I suggest using msg as well: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/msg
Hi all,
Wondering exactly what json I need to put in my PUT request to /fog/task/<IDOFOBJECT>/edit to update it.
Do I need to to include the full JSON object for the task? IE:
#!psuedocode
$original_task=$(curl http://fog.home/fog/task/119)
#...
#edit $starting task into $updated_task
#...
curl -X PUT -d $updated_task http://fog.home/fog/task/119
Or can I just send the updated values? E.g:
curl -X PUT -d {"stateID": "1"} http://fog.home/fog/task/119
Auth via keys is working but not via user & password
christian@SuperDuper$ curl -H 'Content-Type: application/json' 'http://fog.home/fog/task/active' -u api:password -vvv
* Trying 192.168.166.109...
* Connected to fog.home (192.168.166.109) port 80 (#0)
* Server auth using Basic with user 'api'
> GET /fog/task/active HTTP/1.1
> Host: fog.home
> Authorization: Basic YXBpOnBhc3N3b3Jk
> User-Agent: curl/7.47.0
> Accept: */*
> Content-Type: application/json
>
< HTTP/1.1 403 Forbidden
< Date: Thu, 24 May 2018 04:38:01 GMT
< Server: Apache/2.4.33 (Ubuntu)
< X-Frame-Options: sameorigin
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Strict-Transport-Security: max-age=31536000
< Content-Security-Policy: default-src 'none';script-src 'self' 'unsafe-eval';connect-src 'self';img-src 'self' data:;style-src 'self' 'unsafe-inline';font-src 'self';
< Access-Control-Allow-Origin: *
< Content-Length: 0
< Connection: close
< Content-Type: application/json
<
* Closing connection 0
By contrast this works fine:
curl -H 'fog-api-token: MzkyNmQ3MWNkMjNjOTk1MzNiZDU0MzM2MTg3OTQ3MjZiZmI1NjhiNDlhMjM2NDkxMmU5ZjE0YWNkNGUyNGM4MmJhYmZjMDkzMjkyZjFiODIzY2Y0ODQ3M2ZmZjAxYjNmYmZmMDc2NzY1ZmY0ZsomemissingForSecurityreasons' -H 'fog-user-token: OTc3YjkzNDY2NzY5YjQ1OGEzOWE1MTE2Yjc2ZGVlYzI3YzE3ZmQ4MGMyMDZiNjUyYTk3YjRlMjIyYTllYjM0ZGJhYWY3Nuserinfomissingforsecurityreasons' -H 'Content-Type: application/json' -X GET 'http://fog.home/fog/task/active'
Any ideas?
Has this feature been depreciated or something?
For background I want to use basic auth because I will be performing a mass deployment to many isolated networks. The network is providing the security and I want not to worry about API credentials in my scripts.
Thanks!
MOD NOTE: Edited to remove portion of API Token as this is a security hazard.
@sebastian-roth I just started getting this too on Ubuntu 16.04
I am running the clients in KVM VMs and so it should not be hardware.
I already set Ubuntu not to do the auto-update but perhaps missed something here.
@dylan123 There are a few ways to do this – either have selective routing on your layer three devices to the FOG network or just hard switch clients to a FOG VLAN with its layer two environment. Either should work from a compliance perspective.
Agree with all Tom’s points, NFS is not a simple protocol to harden.
What I recommend is VLANing your FOG network so it is manually exposed via your switch configs. Does require managed switching, but will accomplish the task.
@tom-elliott I am having the same issue in 1.5.2.15
Can provide issue as necessary.
@sebastian-roth Not a bad thought.
I enabled the API in FOG Configuration > Fog Settings > API Enabled > Update and copied the API key.
I then created a new user and got their API key.
I am trying this:
curl -H 'fog-api-token: <server token>' -H 'fog-user-token: <user token>' -H 'Content-Type: application/json' -X GET http://fog.home/fog/system/info
And I get a 404:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /fog/system/info was not found on this server.</p>
<hr>
<address>Apache/2.4.33 (Ubuntu) Server at fog.home Port 80</address>
</body></html>
Something else I need to do to enable?
EDIT:
Switched to working branch as per this, no luck: https://forums.fogproject.org/topic/11764/api-broken-after-update-to-1-5-2
Same issue when trying via IP instead of DNS name.
@coconutdog The install script needs to be run from the installation directory.
Make sure you cd to the dir with the install script before running.
I did this:
Put your images in the http server – for me I made a new folder for ISOs /var/www/fog/iso
Then enable plugins and the tasktypeedit plugin.
Once enabled make a new task and add this to the kernel parameters:
&& imgfree && initrd http://${fog-ip}/fog/isos/<name of iso you want to boot> && chain memdisk iso raw
Now when fog runs the script to load the fog kernel after it loads it frees the existing initrd image and loads the your ISO instead.
Now you can boot to ISO via the tasking system.
This is a very rudimentary task and so it won’t mark itself as complete – I am working on fleshing it out so it will. In the meantime you will need to manually remove the task after boot.
@kermit1991 Sounds like a user context issue. I’m not sure on what the snap in engine runs as but I would assume SYSTEM. If this is the case your message would appear on SYSTEM’s desktop, which doesn’t exist.
You can figure out who the snap in is running as by looking in Task Manager or testing e.g. ‘whoami > %temp%\snapinuser.txt’ – this will print the username running the script.
I suggest using msg as well: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/msg