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/119Auth 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
I have added the Task Types plugin and have a working task that boots me into an ISO.
I have accomplished this by putting this into the kernel arguments: && imgfree && initrd http://${fog-ip}/fog/isoimg/LiteTouchPE_x64.iso && chain memdisk iso raw
My understanding is that this effectively “hijacks” the boot sequence by slipping in my ISO after FOS loads successfully.
Is there a way that I can can mark the task complete right before I boot into the ISO?
Where can I find the existing tasks so I can view the source?
Thanks!
@george1421 Excellent…uhh…how do I mark this as solved?
@sudburr @george1421
Unfortunately neither of those worked for me – maybe a Win10 1709 thing.
I ended up setting up autologin and setting a PowerShell script as the shell for first logon. This was done via FOS registry edits.
This script installs the drivers and sets the shell back to Explorer.
Note this does require a hardcoded Administrator password.
Working on an improvement now that will set the built-in admin pass via chntpw as well. This will allow an image captured from uknown hardware to be redeployed with new hardware (even when you don’t have the benefit of sysprep / Administrator user setup).
If you’d like to view my progress see here: https://github.com/grlcboi/fogscripts
@george1421 I did borrow heavily from your 2017 tutorial and will be putting you the readme.
Fixed for now: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy
Had to reblank the root password
Is there a way to put a password in FOG so the password doesn’t have to be blank?
Fog server was working fine yesterday but today I’m getting “Database connection unavailable”.
mysql systemd unit is running fine on Ubuntu 16.04.
Any ideas?
@george1421 I was able to add a task with the Task Type Management plugin.
With the below added to the kernel args I am able to boot to iso:
&& imgfree && initrd http://${fog-ip}/fog/isoimg/LiteTouchPE_x64.iso && chain memdisk iso raw
Is there a way I can chain a “Fast Wipe” task right before the boot?
I am looking through the source for the Fast Wipe task definition but can’t seem to find it.
@george1421 How do I turn off driver signing requirements?
Tried via Local Group Policy, BCDEdit, no luck.
Thanks for all your help.
Hi all,
I added a custom iPXE menu item to boot from an ISO (MDT).
Is there a way to create a custom task so I can trigger this option from the web GUI?
@george1421 I’m having this same issue of course – just wondering if anybody had any update on what’s working with 1709?
Putting the path on offlineServicing does not work (and in fact does not seem like it should as it runs during setup IE image generation).
Altering HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\DevicePath also does not work.
Using pnputil via SetupComplete.cmd runs into issues if the drivers aren’t signed (currently giving this a go).
Currently giving dpinst.exe a go.
