Latest Development FOG
-
Using Subversion
[CODE]apt-get install subversion[/CODE]… to retrieve the SVN of FOG only works on a ‘checked out’ version of FOG that was retrieved by using subversion itself:
[CODE]mkdir /opt/svn && cd /opt/svn && svn checkout [URL]https://svn.code.sf.net/p/freeghost/code/trunk[/URL][/CODE]On a virgin system where the FOG SVN was downloaded via:
[CODE]cd /opt && wget --no-check-certificate [URL]http://mastacontrola.com/fog_trunk.tar.bz2[/URL][/CODE]… then extracted and installed by:
[CODE]cd /opt && tar -xvjf fog_trunk.tar.bz2 && cd /opt/fog_trunk/bin/ && ./installfog.sh[/CODE]Running:
[CODE]cd /opt/fog_trunk && svnversion[/CODE]… elicits:
“Unversioned directory”
It’s only fair that the .tar.bz2 download can’t be expected to be the same version as the `checked out’ version; hence downloading the FOG SVN using:
[CODE]cd /opt && wget --no-check-certificate [URL]http://mastacontrola.com/fog_trunk.tar.bz2[/URL][/CODE]… you can then
[CODE]cd /opt && tar -xvjf fog_trunk.tar.bz2 && cd /opt/fog_trunk/ && grep FOG_VERSION packages/web/commons/system.php | sed “s/^[ \t]define(.FOG_VERSION., .([0-9.]).);/FOG Version: \1/”[/CODE]… to determine the version of what you just downloaded by this secondary method.
-
Hmmmm,
If you downloaded from my website, you DID NOT DOWNLOAD FROM SVN!
Perhaps, I’m being too harsh?
-
This may be the basic misunderstanding I developed.
I believe I got there by using your site to retrieve an unofficial kernel from way back that solved some serious NIC issues we once had.
I continued referencing your site as the source for the latest trunk of FOG, including this post in this same thread:
[QUOTE]Grabbing a version number from [URL=‘https://svn.code.sf.net/p/freeghost/code/trunk/’][U][COLOR=#0066cc]https://svn.code.sf.net/p/freeghost/code/trunk/[/COLOR][/U][/URL] doesn’t help me in identifying a downloaded trunk file.
This afternoon I saw 2093 posted as [URL=‘https://svn.code.sf.net/p/freeghost/code/trunk/’][U][COLOR=#0066cc]https://svn.code.sf.net/p/freeghost/code/trunk/[/COLOR][/U][/URL] , so I immediately downloaded [URL=‘http://mastacontrola.com/fog_trunk.tar.bz2’][U][COLOR=#0066cc]http://mastacontrola.com/fog_trunk.tar.bz2[/COLOR][/U][/URL] .
When the download completed I revisited [URL=‘https://svn.code.sf.net/p/freeghost/code/trunk/’][U][COLOR=#0066cc]https://svn.code.sf.net/p/freeghost/code/trunk/[/COLOR][/U][/URL] and it had changed to 2094. Which version did I just download? [/QUOTE]
So NOW I understand. There is the SVN and then there’s your private tarball which I mistakenly latched onto.
Meanwhile, this still works:
[CODE]Installed:
grep FOG_VERSION /var/www/fog/commons/system.php | sed “s/^[ \t]define(.FOG_VERSION., .([0-9.]).);/FOG Version: \1/”Run from within extracted fog_trunk directory:
grep FOG_VERSION packages/web/commons/system.php | sed “s/^[ \t]define(.FOG_VERSION., .([0-9.]).);/FOG Version: \1/”
[/CODE] -
While I do try to keep the tarball updated, sometimes I may make multiple svn updates before one tarball has the chance to update.
Once I’m done doing the frequent changes, I’ll run my tarball script which helps keep the private tarball updated.
I only keep it there for simplicity. It, for all purposes, is the SVN just without any of the SVN information so to keep the size small.
-
The BTSync is also still quite popular for seeding the latest updates.
Main Fog BTSync - BAU3NUY3XTKVMHHEZO6C7OH55AN2PCGJV
Fog Kernels - B7AGQ6JVIP4MF5LCRL3XURQBYC53UIS25both are read only secrets and get updates as soon as theyre put in
-
SVN 2342 released.
I know, I know, it’s been a while again. With this comes many more fixes and enhancements.
Time formats aren’t in “Today, HH:mm” or “Yesterday, HH:mm”, they’re in formats of “## Seconds ago, ## Minutes, etc…”
This also comes with better cron style verification methods so you can now schedule with comma’s, dashes, and/or slashes. All should be operational in this mode though I will admit I’ve not the capacity to test all possible combinations.
Nearly all times are now using DateTime formats.
I’ve also moved the deploy and deploy_post methods from the Group Management and Host Management pages to the FOGPage class. This means the two main modes of deploying tasks are common in how they operate and display success’s or failures. I think it’s a rather nice change as trouble shooting things can be done from one file rather than two.
I hope to get the basic tasks links for both of these pages to operate in a similar fashion only showing what for the relevant page.
-
SVN 2343 released.
With this release comes the movement of the basic task parts to the FOGPage class rather than coded individually for both Hosts and Group pages. Also moved the Active Directory display fields to the FOGPage class as well.
-
SVN 2352 released.
With this release comes many fixes and method changes to how we approach Cron style tasks. One, we can now get the next run times. Two, the cron tasks are checked as a whole cron string rather than a series of checks. Three, the validation of the stuff happens similarly. You can actually create tasks with #-#/# or */# or #/# or #,#,#,#,# or any of the normally valid cron style taskings.
I haven’t yet figured out if the DOW or DOM actually operate as expected, though from what I can tell it should without too much issue.
Hopefully all will enjoy this as it took a lot of time and research. All I can say, is finally, cron tasks operate like cron tasks. Sort of at least considering they’re being run from a simple php system rather than through a real cron tasking.
-
SVN 2387 released.
With this comes some improvements to the interface. Dynamically adding events to the hook manager is kind of possible. Maybe others know a better way? The way it works now, it scan’s all php files in management, lib/pages, lib/plugins/<plugins>/pages, and lib fog, maybe more, and reads all the processEvent calls. It then scans that particular element to get the event name and send it to the events variable.
This could result in a slower performance, but it doesn’t seem too much off from what I usually see. This helps me lessen the amount of code needed to look for things.
Also, other changes since last updated.
MAC’s are now stored in a single table.
I plan to add a few new features, such as ignoring a MAC from from clients (and later imaging too). It caused a couple headaches but should be good now.
-
I can’t seem to find it and It feels like monday whats the terminal command to pull fog with…
-
[CODE]svn co https://svn.code.sf.net/p/freeghost/code/trunk <where ever you want to save the downloaded code>[/CODE]
-
[quote=“need2, post: 37606, member: 21891”][CODE]svn co https://svn.code.sf.net/p/freeghost/code/trunk <where ever you want to save the downloaded code>[/CODE][/quote]
Thank you… i want a do over… on this week… let it be friday night again.
-
SVN 2408 released.
This has many mods and should fix many separate issues, if not all that have been occurring. In earlier svn releases.
-
SVN 2418 released.
With this comes, after a slight break, the Client Ignore and Image Ignore checkboxes should work. I know the client works, but haven’t quite fully tested the imageIgnore option though from all appearances it should.
-
2419 released.
The problem with the prior approach, while it worked, it reported the host as invalid, which is not necessarily true. So now bootmenu handles for the tasking portion if there is a task for the host.
Services are handled appropriated from what I can tell as well.
-
SVN 2426 released.
With this comes a new plugin for WOL Broadcast Address management.
The idea of this is to allow for people who don’t have access to adjust their networks to send across their relevant broadcast networks.
It’s not perfectly ideal, but the way it works when in use is to send to all of the networks in the list. It also maintains the sending of WOL packets to the main broadcast address of 255.255.255.255. Hopefully this helps you all out.
-
SVN 2429 has bandwidth graph functionality back. It is no longer reliant on the selector.
It will display all nodes and display the colors related to those nodes. There are labels to help you stay knowledgeable on what’s what.
-
SVN 2441 released.
This comes with a new db schema change.
The change is to include a “success” table of the files people use to boot with. Later will come a “report” to be able to give us more a clue.
The idea of this, until ipxe.kpxe/kkpxe can determine if it can use it’s native drivers and switch to undi if it can’t, a method to later on programmatically code what file to load depending on the finding of the success/fail table.
My hope is to get a central location where the local table can be uploaded so we have a more broad knowledge of exactly what systems work with what files. Particularly, which systems operate best with ipxe.pxe and which require the use of undionly.kpxe or undionly.kkpxe.
This isn’t something that’s going to happen overnight. The table has been created and it uploads once the system boots into the bootmenu. If it can get to the boot menu, it’s a pretty safe bet the boot file works.
The table structure is:
id (the inserted item for reference later on)
product (what the product of the system is)
manufacturer (what the manufacturer of the system is)
mac (only used as a stability thing, isn’t really required I don’t think but could be useful to determine nic manufacturer)
file (the file that is being booted from. This is picked up at boot time through the Option 67/filename setting of your dhcp server)- NOTE * The reason for the file using the filename. I’m going to be making requests on an off about which file to use. Rather than simply changing the file name to undionly.kpxe as I’ve requested in the past, I’m going to start making requests to change the filename/option 67 so we have a more accurate filename to compare against.
success (if the system boots to the file it’s successful)
failure (it it doesn’t boot it’s a failure. I don’t know how to make this work though, maybe assume all failures and set to success if it gets to the menu?)
Hopefully this makes sense and we as a community can build a better functioning product.
Also, this particular table can be used to report back to the iPXE team so they can maybe help with programmatically making this happen without the FOG team having to do it directly? Also, it will help them with updating their supported systems and maybe fix unknown drivers and so forth.
So as the community contributes (without you having to do anything specific) we’re not only helping ourselves, but the good guys over at iPXE.
There’s a few other items in this release, but this I think deserved the most mention. The other things that have been added are:
HookManager received, once again, the getEvents method is back. It was removed for performance reasons. I brought it back, but it will only be used for the HookDebugger hook as it needs to know what events exist in order to operate. This should affect many, but for those trying to create their own hooks and or plugins it can be useful.
Changed methodology of picking up the ob_start(‘ob_gzhandler’) and ob_end_clean() to use ob_end_flush(). This function pushes the data without clearing what was sent which cause issues with hooks in general. The hooks system is enabled before the content and page is setup, so there’s no data to work with. It needs the data to be available to hook into it after it’s been loaded. Under ob_end_clean, it works most of the time, but where the data isn’t really parsed it can’t operate. ob_end_flush pushes the cache back to the browser but also allows the data sent to be worked against with the relevant hooks.
Through playing with many database systems, you can setup what’s known as persistent connections. To enable persistent connections, simply add the characters p: before the ip of the host (e.g. p:localhost, p:192.168.100.15) to your Config.class.php file. This isn’t really an added feature just something I thought to note. To help with handling multiple queries and such, I also added the ability to kill the opened thread and properly close the links in the db. This shouldn’t hurt or improve anything more than simple memory management on your server. This is how I found out about the persistent connections and just though noting it would be useful here as well.
The Hooks that come with FOG natively work more properly. SubMenuData can properly be hooked now. Just view the SubMenuData.hook.php (new one) to see what’s changed and how to operate with the submenu data.
This same method works for the plugins as well. You can completely hook in the requires of your plugin for pages and such without having to code the main source for things to function.
- NOTE * The reason for the file using the filename. I’m going to be making requests on an off about which file to use. Rather than simply changing the file name to undionly.kpxe as I’ve requested in the past, I’m going to start making requests to change the filename/option 67 so we have a more accurate filename to compare against.
-
The changes in HookManager.class.php give problems
[Mon Oct 20 13:28:54 2014] [error] [client 158.227.4.135] PHP Warning: array_push() expects parameter 1 to be array, null given in /var/www/html/fog/lib/fog/HookManager.class.php on line 67, referer: [url]http://fog1.ehu.es/fog/management/index.php[/url]
[Mon Oct 20 13:28:54 2014] [error] [client 158.227.4.135] PHP Warning: in_array() expects parameter 2 to be array, null given in /var/www/html/fog/lib/fog/HookManager.class.php on line 66, referer: [url]http://fog1.ehu.es/fog/management/index.php[/url]The WEBUI is KO
-
For more info
[url=“/_imported_xf_attachments/1/1440_Error_HookManager.png?:”]Error_HookManager.png[/url]
