Best posts made by Tom Elliott

Hey all,

Normally I make a proper news article to post in the announcement but I don’t think we should go that route for this particular bit of news.

I’ve already tested FOG Trunk with PHP 7.0.0 RC8 and fixed the code base to be as operational as possible. Even better, due to all the other edits from about a year ago, I already had a good starting point. For example, not using mysql functions and what not. All I had to change was removing one line of code and all of a sudden everything starting working perfectly with it.

I will say, PHP 7 is MUCH more memory efficient and a LOT faster. For example, on PHP 5.6.16 the dashboard page on a server that only had FOG installed on it would come in around 9M. Same principle with PHP 7.0 installed, the same page used 2M of memory. This means quite a lot. I also played with injected hosts and had 4k hosts. 5.6.16 would take about 6 - 7 seconds to start returning the page and about 16 - 18 seconds to fully render the page. With PHP 7.0 the same amount of hosts on the same system returns in about 3 seconds, and fully renders in about 12. While the timing for amount of data doesn’t seem all that significant the memory usage is MUCH better. 5.6.16 would come in around 168M, 7.0 Comes in at about 130M.

I know this is nothing but gibberish, but believe me, if you can update, I would HIGHLY recommend it. One it would be nice to know of any problems I might have in the code, and two it would definitely help out those of you who have MANY MANY hosts in your setup.

Maybe my two cent’s can matter a little?

I like the idea of having a VM appliance, regardless of the OS used to do this. I would, for most, recommend using a headless OS. VM’s have a lot of potential, but they also share their resources. I know you all know this already but figure somebody who may happen across this thread, not knowing this same information, would understand more readily.

That said, because not everybody is as skilled with *nix systems, I agree that a lightweight GUI would be helpful. Maybe having two appliances, a headless and a GUI based appliance would be best? I could, potentially, build a custom appliance for headless using a hand made Linux? (It would be extremely lightweight as I can do LFS and get OS in at around 200 - 500 MiB of use)

@Wayne-Workman Users most definitely know what they’re getting into if they’re going to be doing an Appliance as such, and if not, we have some pretty decent (albeit not the best quite yet) documentation on how to do simple things such as adding a new disk or expanding a volume. 250GB may be a bit high on the disk space side though and I would recommend maybe making it as small is 50GB. I only state this because We can/should not assume the appliance this is being put on WILL have 250GB. In the documentation we should put something informing the users that it is highly recommended to use a larger disk and give related information (Expand/Add storage).

@VincentJ While I see where you’re coming from in that having a netinstall CD would be nice, I think it’s a bit too much to expect. If we’re already so worried about users not knowing what they’re doing, why would we give them more opportunity to make a mistake by having them install the OS itself?

As for the OS to use, whatever works. While I may not be a fan of Ubuntu, Debian is one of my favorites. I may be more comfortable in RH variants, but I am not trying to code the installer to take preference to an OS. If we make an appliance, it should be what the majority will most likely use on their systems if they were to do the install entirely themselves. Because there’s more videos on the net about installing fog that use Ubuntu, I’d actually recommend using Ubuntu. More people are already somewhat familiar with this OS so it would not be any major learning curve, and I have to give credit that Ubuntu is also, in my eyes, one of the easiest linux distro’s to use for those who have NEVER used linux before.

@kirkk can you please update once again, and try again?

I believe I fixed the init_32 issue. Your image most likely is partclone, and the reason things failed was because it didn’t matter which method you used to image, pigz was not working properly on 32 bit. I think this is now fixed, though I need people to confirm.

Thank you,

Fix should be pushed. It was, semi, related to location, but indirectly.

The hook that processes for the bootmenu in this case was not setting needed variables first. This should now work as intended, of course please update and test.

https://news.fogproject.org/fog-1-3-0-rc-3-3/

(Had mistake when saved proper link is accurate though).

Right now there isn’t much in terms of documentation. We are working toward getting there.

Understand the API system is very new, but as much as I could “simply” implemented.

What I mean with this:

1. Data body or return is done with JSON.
2. All objects in the core have some ability to managed with the API system with the only exception, so far, being Users.

There are a few important bits in regards to interacting and using the API System.

1. API Can be globally enabled/disabled.
2. API Can be user enabled/disabled. – (You can define which users you want to have access to the api system.)

Tokens:

1. API Global token is a header required with the name fog-api-token
2. API User token is a header that can be used (Highly recommended) being passed as a header in the form fog-user-token
3. You can not manually create the tokens via the presented text fields. This is what the purpose of the “Reset Token” Buttons are. There’s a Reset Token for the global API as well as one for each user.
4. Tokens are cryptographically generated so no two tokens will be known regardless of how many FOG Server’s you decide to install. There is no “default” token essentially. This holds true for both User and Main API Tokens.

Authentication:
You can use HTTP Basic Authorization (with curl -u <user>:<password> or header with name Authorization: Basic <base64encoded username:password>
Although I have allowed the ability for this type of authentication, and it will work, I would still recommend using user token system as it cannot be received and decoded to a valid username/password pair to manage your fog server.

Routes and Methods:

GET

1. /fog/system/info Returns 200 if accessible
2. /fog/system/status Alias for #1
3. /fog/<objectactivetasktype>/current Returns listing of “active” items. Active referring task types, (Snapin Task, Snapin Job, Task, Scheduled, Multicast)
4. /fog/<objectactivetasktype>/active Alias for #3
5. /fog/<object>/search/<whatareyousearchingfor> Idea is similar to the Search Page from GUI.
6. /fog/<object> Same idea as “List all”
7. /fog/<object>/<IDOFOBJECT> Same as if clicking edit on an item (only just to get its information).

PUT (Requires a json body)

1. /fog/<object>/<IDOFOBJECT>/edit Update the object.
2. /fog/<object>/<IDOFOBJECT>/update Alias for #1

POST (Requires a json body)

1. /fog/<objecttasktype>/<IDOFOBJECT>/task Task object.
2. /fog/<object>/create Create new object.
3. /fog/<object>/new Alias of #2.

DELETE

1. /fog/<objectactivetasktype>/cancel Cancel specific items (requires json body)
2. /fog/<objecttasktype>/<IDOFOBJECT>/cancel Cancel specific task for object.
3. /fog/<object>/<IDOFOBJECT>/delete Delete/Remove object.
4. /fog/<object>/<IDOFOBJECT>/remove Alias of #3

HEAD

1. /fog/system/info Returns 200 if accessible
2. /fog/system/status Alias for #1

I realize this is not a full on “here’s everything” but it’s something that should be able to help get you along the path.

Core <object>

1. clientupdater
2. dircleaner
3. greenfog
4. group
5. groupassociation
6. history
7. hookevent
8. host
9. hostautologout
10. hostscreensetting
11. image
12. imageassociation
13. imagepartitiontype
14. imagetype
15. imaginglog
16. inventory
17. ipxe
18. keysequence
19. macaddressassociation
20. module
21. moduleassociation
22. multicastsession
23. multicastsessionsassociation
24. nodefailure
25. notifyevent
26. os
27. oui
28. plugin
29. powermanagement
30. printer
31. printerassociation
32. pxemenuoptions
33. scheduledtask
34. service
35. snapins
36. snapinassociation
37. snapingroupassociation
38. snapinjob
39. snapintask
40. storagegroup
41. storagenode
42. task
43. tasklog
44. taskstate
45. tasktype
46. usercleanup
47. usertracking
48. virus

Core <objecttasktype>

1. group
2. host
3. multicastsession
4. snapinjob
5. snapintask
6. task

Core <objectactivetasktype>

1. multicastsession
2. scheduledtask
3. snapinjob
4. snapintask
5. task

Routes that allow filtering with JSON body passed

GET

1. /fog/<object>
2. /fog/<objectactivetasktype>/active
3. /fog/<objectactivetasktype>/current

DELETE

1. /fog/<objectactivetasktype>/cancel

Plugin’s Compatibility.

I have worked relatively hard to implement capability for plugins to also tie in with this. This means hooks can be used to implement API level functionality with plugins or custom elements you’d like to use.

Hook Event Names what core element it ties in with:

1. API_VALID_CLASSES, variable to adjust is labeled ‘validClasses’. Ties in with <object> items.
2. API_TASKING_CLASSES, variable to adjust is labeled ‘validTaskingClasses’. Ties in with <objecttasktype> items.
3. API_ACTIVE_TASK_CLASSES, variable to adjust is labeled ‘validActiveTasks’. Ties in with <objectactivetasktype> items.
4. API_MASSDATA_MAPPING, variables to adjust are labeled ‘data’, ‘classname’, and ‘classman’. Operates on the “list” and “search” type routes.
5. API_INDIVDATA_MAPPING, variables to adjust are labeled ‘data’, ‘classname’, and ‘class’. Operates on individual objects such as /fog/<object>/<IDOFOBJECT>
6. API_GETTER, variables to adjust are labeled ‘data’, ‘classname’, and ‘class’. Operations for all items and is used to present the return of data in a common way regardless of what object is being called.

• In regards to #6 of the Hook Event elements, think of it as this:
  If I request information about a task, one of the elements of a task is the “host” object. The data presented in the “Task” return for a specific host will look the same in the task return as it would if you looked the host up individually. For example, if the task is using a hostID of 7, the ‘host’ item in this element would look identical to the return data if you were go to route /fog/host/7

To ensure you don’t have to do this on every update/install of FOG, you may want to edit the /opt/fog/.fogsettings specifically the snmysqlhost, snmysqluser, and snmysqlpass fields to contain the information relevant for your MySQL setup.

What about disk usage?

https://news.fogproject.org/fog-1-3-5-rc4/

@eroldin windows allows the use of - or / for argument switches.

If at all possible, create a raw backup first, then try the upload. This way, if everything get’s borked, you could recover it as is and not have to redo all the work again and again. Or created it in a VM and take snapshots.

The updater script was never compatible with trunk. However, (drum roll please), it is now.

You will have to update your sources first but all should work.

Of note, I have a check to see if you’re trying to install trunk. If this flag is not specified it assumes you want the latest stable version. To keep trunk upgraded add trunk='yes' to the /opt/fog/.fogsettings file and you should be all set.

https://news.fogproject.org/fog-1-3-5-rc-6/

Removed. Well, kept the surface-pro-4 matching element, but just removed the 7156 portion.

@Trevelyan I’ll fix the hosts and users report when I get into work.

Can you all verify if things are better and let me know? I’m sorry about the problem this caused, but hey progress or something.

Found and confirmed. The auto increment part broke this. I’m sorry I missed the _ in AUTO_INCREMENT so the table failed to create.

I’ve pushed a fix for this. If you lost db, please use one of the sql files from before this change and you should be able to recover.

https://news.fogproject.org/fog-1-3-5-rc-7-and-fog-client-version-0-11-10-released/

Just to chime in here, 1.6 is now setup with innodb as default. So while we discuss things for 1.5.x, just know that this has been corrected.

I’m adding code to the add-apt-repository element that will: #NOTE this is specific to Ubuntu/maybe Debian

1. Try installing the ppa.
   a. ensure python-software-properties, software-properties-common, and ntpdate are installed.
   b. update the date on the server
   c. attempt adding the repository.
2. If it cannot install the ppa:
   a. Update the repository data (apt-get update)
   b. Install python-software-properties and ntpdate
   c. Update the time server.
   d. Ensure the en_US.UTF-8 locale is generated on the system
   e. attempt adding the repository with: LANG='en_US.UTF-8' LC_ALL='en_US.UTF-8' add-apt-repository -y ppa:ondrej/php5-5.6

Hopefully this will prevent any more such issues and you’ll have an updated time system.

SHould be fixed in latest, please update again.

Sorry that’s the last time I try to cater to a warning thrown that isn’t really impeding function.