Latest Development FOG
-
SVN 2248 released.
Once again, I’m falling behind the curve. Hopefully you all understand that this is not for a lack of trying, but rather a progression in work I’m attempting to get done.
With this release finally comes the ability to customize Menu Items. I will think about the ability to adjust the order of menu items, but for now this will have to do.
First and foremost. All items can be displayed in a new menu item called iPXE Menu Configuration. You will see all menu items as their own entry. The first 12 entries main fields are disabled from editing. The reason for this? Because I want to make sure you have the default menu entries we all use. If you start editing them, this may break the menu structure. That aside, you can adjust with which items are defaulted, even for the 12 that are disabled. You can also change which items they fall under. There are three main items. Non-registered Hosts, Registered Hosts, and All Hosts. These do as you might expect. If it’s all hosts, the menu entry displays on all menu’s regardless of if the host is registered or not. Non-registered Hosts items only display on hosts that are not registered. Registered hosts only display for hosts who are registered. Hopefully that makes sense. There are three others though. The Debug Options, Advanced Options, and Advanced Login Required. They’ll be unlikely to do anything for your particular new menus and I’ll think about adjusting this so it’s more proper. This field just helped me setting up the new system.
New menu items can be created through the next link called iPXE New Menu. This just presents a set of fields so you can create your own menu entries.
I’m sure there’s some kinks to work out and ask that you, the community, try to help me with this as I’m trying to make this as dynamic as possible.
When creating a new menu entry, you Must, at the least, specify Menu Item: which is the item flag that get’s called to boot the system. You must also specify a description (the neat name for the menu entry) as well.
If params is set, you will have to add a new method to rework the BootMenu which can be done with hooks, theoretically. I haven’t tested this aspect, but it should allow a method to work around new items that you want to do specific things such as changing a host name or what have you. If you’re worried, you could still edit the BootMenu file directly to pass through information. I have to figure out a way to allow this to be stored, and retrieved, from the database so things will be more dynamic and be maintained on updates, but for now it’s my best course of action.
If options is set, it will pass to the os layer calling the bzImage and init.xz files for that menu entry passing the options as command line kernel arguments. This is one method to get you a “bypass” methodology. You will need to specify the img, storage, web, imgType, and imgPartitionType. Yes, partition types can now be specified though I’ll request fractal’s assistance in documenting how to use it.
You can also delete menu items, unless they’re of the first 12 entries of course.
Of note, while you can delete the capone menu items and edit them to your liking, if you delete the capone menu item, it will be regenerated the next host that reboots. It will be regenerated with the normal defaults capone expects. After it’s generated, you are able to edit it as it’s outside of the first 12 items.
While it’s most definitely not a perfect solution, it should at least help add custom entries as so many have been requesting it.
I will be trying to improve it, and those with coding skills and methods to help make this easier are more than welcome.
-
SVN 2263 released.
With this release, temporarily, torrent-cast may be broken on newly uploaded images. However, it also maneuvers the resizable methodology aware from specifying the partitions and generate them using the same method MPS/MPA use only shrinking the partition first. This should allow OEM resizable imaging to work as it’s not taking account of the “defaults” set by microsoft.
I don’t have an OEM image with recovery and stuff to test, so please go forth and try it out if you’d all be so kind.
Thank you,
-
SVN 2269 Released.
While only a few past this time
This release comes with the following:The “new” methods of resizable images appears to work with Multicast imaging as well. It tries to first detect if sys.img.000 exists, if so, use the “old” methodology behind resizable images. Otherwise, it uses the same effects of the Linux resizable constraints. This works for Multicast and Unicast images, but may temporarily break Torrent Casting on new images as stated above already. On the files that sys.img exist, you shouldn’t have any issues. It may take me a bit before I can get torrent casting working on the new methods as I need to find a means to specify the download partition and create it.
With this also comes an image protection feature. A simple checkbox on the editing of an existing image that specifies whether or not to protect your image. It does not run chattr +i to the image folder so command line junkies will still be able to remove the contents of the files, but this is not a typical thing people just “do” from my experience. chattr +i was more used as a means in the older versions of fog because it was quick and easy to protect your image, but there was no way to know if it had been turned on and/or disabled. At least here we can see if it’s protected or not and update as needed.
-
Hi, i created images in svn rev 2209 i think it was, then updated to 2307 but after image is deployed the machine never restarts just sits waitinng so then i rolled back to the latest stable version 1.2.0. Now when i attempt to deploy said images down to the same machine it states cannot find sys.img.0000 (may not be exactly right) is this because images are no longer compatible in later svns ? from looking at it single disk resizable in 1.2.0 names the uploaded files as sys.img.0000 etc but doing the same in the latest svn names the uploaded files as dp1.img etc.
-
[quote=“sudburr, post: 33646, member: 4706”]Short of installing, is there a file in the trunk that indicates the svn?[/quote]
Just to note the following command, run from withing the root of the trunk folder, will provide the version number in the system.php of the trunk contained within the folder.
[FONT=arial][COLOR=#222222]grep FOG_VERSION packages/web/commons/system.[/COLOR][/FONT][FONT=arial][COLOR=#222222]php | sed “s/^[ \t]define(.FOG_VERSION., .([0-9.]).);/FOG Version: \1/”[/COLOR][/FONT]
Until at least the coders change how they define the FOG version.
[FONT=arial][COLOR=#222222]FYI[/COLOR][/FONT]
-
Or a simple:
[code]svnversion[/code]
In the trunk folder will tell you the current svn version.
-
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.
