FOG Status
-
I agree to that, Andy. My FOG server and Unix storage server have around 180 days of uptime in production. If I don’t power cycle the Windows servers once a week or so they start to get stale.
-
FOG is arguably the best application in the known world and I am deeply interested in its future. The creators and developers of this amazing piece of software are truly living geniuses, gods among men, and I am eternally grateful for their work.
Since the only constant is change, I would like to just throw a few things out there as a FOG user…
I have had great success with the FOG service and I actually really like that integration; that being said I know that it is hard to develop and maintain. I have never really used:
Auto Log Out
Directory Cleaner
Display Manager
Green FOG
User Tracker
User CleanupBut please, oh please keep the Hostname Changer and Host Register with the AD integration (they have continued to work well for me in Windows 7, x86 and x64 - Windows 8 worries me regarding this, but hey, it is NT 6.2, right?) I could live without the FOG tray, but the FOG service with those two features along with Task Reboot and Snap-ins would be so, so nice to still have because it makes FOG a complete imaging, auto-naming, program-deploying solution and I have never, ever seen any other application that does this so elegantly and so well - not by a long shot. I also really like the ability to load all those tests from the web UI. I’ve had varying degrees of success with most, but consider memtest almost essential for field testing. I know that a lot of these things can be loaded up over USB or other ways, but FOG’s integrated delivery is just so much better.
I will also throw my hat in the ring on the NFS share issue - we have backups but this hurts the enterprise “strength” of the system simply because people worry about stuff, often unnecessarily. I would also like to see some kind of automated or scripted way of managing the SQL database password for the same reason.
I also like the Linux/Debian/Ubuntu environment for all the reasons others have mentioned, and don’t much see the point of having the core application running on another platform. To me, that is what the web UI, SSL, and RD are for.
Lastly, I am part of the crowd that has yet to face UEFI/GPT in a large way, but I know that it is coming, soon; I agree that this is probably the biggest single issue on the horizon and it does apply to me too.
Beyond that, I honestly think that FOG is nothing short of a godsend, and seeing it in action and how well it works truly amazes me on an almost daily basis, so it is funny to me to hear the “lipstick on a pig” analogy applied to something so amazing!
Thank you again, thank you so much,
D.L. -
This post is deleted! -
[quote=“andyroo54, post: 17752, member: 267”]I’m not really sure I understand this.
Snapins work flawlessly for me. They are without doubt one of the best features of FOG in my opinion. If there was a seperate distrubtion where all it did was deploy snapins to clients I would be happy.
Can you explain what you mean by ‘better way’?
[/quote]
The deployment method is fine my comment is geared towards the encapsulation apps e.g (InstallRite & SFXMaker)
-
[quote=“The Dealman, post: 17970, member: 53”]The deployment method is fine my comment is geared towards the encapsulation apps e.g (InstallRite & SFXMaker)[/quote]
I use SFX maker and have no problems with it, it is not related to FOG though?
-
[quote=“andyroo54, post: 18001, member: 267”]I use SFX maker and have no problems with it, it is not related to FOG though?[/quote]
what’s the largest snap-in you have deployed?
-
[quote=“The Dealman, post: 18013, member: 53”]what’s the largest snap-in you have deployed?[/quote]
Office 2010 it’s about 1GB
-
My 2 cents.
[LIST]
[]Could FOG become its own distribution? Maybe even a TurnKey Linux patch or similar to ease packaging
[LIST]
[]Could ease compatibility, as everything is tested together before shipped as an ISO or VM image
[]being based on a modern Ubuntu LTS means better hardware compatibility for Bare metal install’s (who does this nowadays?)
[]Don’t think installing on windows is a good idea at all personally, I have always treated FOG like an appliance, it just works!
[/LIST]
[/LIST]
[LIST]
[]Without starting a programming language flame war
[LIST]
[]As for changing over from PHP I personally agree with this, although there are a lot of PHP dev’s out there, I would choose a more popular language though. I find Python (Django) really easy to work with and might make for quicker dev time
[/LIST]
[/LIST]
[LIST]
[]UEFI
[LIST]
[]I know its tricky, particular to get secure boot working, unfortunately I can’t help with this one
[/LIST]
[/LIST]
[LIST]
[]As for all the extras like password reset etc
[LIST]
[]Get rid of them. Because FOG includes a PXE server its very easy to use Memdisk to boot any ISO you want, so no need to Integrate that extra work into the FOG kernel, let 3rd party apps do it, I have a PXE menu of over 100 ISO tools atm
[/LIST]
[/LIST]
[LIST]
[]I would love to see improvements in FOG’s scale ability
[LIST]
[]Multi-Site improvements and site replication built in with no mods
[]Make it modular in Roles, when you do the install you choose what you want on that server, small sites deploy one single server all roles, large sites scale as they see fit
[]Option to Split Snap-In deployment separate from Image deployment in the roles
[]some form of load balancing / HA , like DNS SRV or Round Robin - easier than clustering
[/LIST]
[/LIST]
[LIST]
[]KISS approach
[LIST]
[]let FOG focus on what its great at, Image and Snap-In deployment leave the rest for 3rd party tools
[/LIST]
[/LIST]
[LIST]
[]Commercial Support
[LIST]
[*]might be dreaming, but I know that we rely on FOG so much that having support would be great, and ease managements mind on how much we rely on this thing. haven’t installed windows manually for years!
[/LIST]
[/LIST] -
[quote=“StylusPilot, post: 18228, member: 441”]My 2 cents.
[LIST]
[*]Could FOG become its own distribution? Maybe even a TurnKey Linux patch or similar to ease packaging[/LIST][/quote][LIST]
[/LIST]
I love this idea, and agree with all of your points.I love the idea of a Fog distro.
-
[quote=“Gilou, post: 15665, member: 3221”]
You are saying the dependency on NFS, TFTP & ISC DHCP is an issue. It is not. Those tools work, they work fine, and FOG is an important part of a network infrastructure, so considering running it on Linux because it uses some of the usual linux toolset is reasonnable.
[/quote]Absolutely right. Considering the project ist struggeling having not enough time for development, so don’t kill the things that really are working and get maintained for you. Use the tools which do work since years and use more of them (-> packaging, dependencies and all the beauty of dpkg) like this you get your hands free for the actual job FOG must do.
Don’t invent the wheel again, go rolling with the wheels you have! -
[quote=“andyroo54, post: 18229, member: 267”][LIST]
[/LIST]
I love this idea, and agree with all of your points.I love the idea of a Fog distro.[/quote]
I will love to have another server with another distro I have to learn again. And I am sure it will save a lot of time to the FOG developpers… No sorry, wrong way.
-
I wasn’t referring to starting from scratch and creating an entire OS eg Ubuntu or over complicating in that manner.
Using something like TKL or others as a base would ease compatibility and includes both deployment options (ISO and VM Appliance), rather than having to test and get FOG to work on SUSE, Ubuntu, CentOS etc
standardize on one base, and ship it as a complete ISO or VM app
or take the approach from other embedded distro’s like FreeNAS or pfSense choose one underlying rock solid base (FreeBSD) and allow easy upgrades including the entire OS via the web UI. This option would also make it easier for commercial support, as its one OS under the hood to support.
-
[quote=“StylusPilot, post: 18377, member: 441”]
or take the approach from other embedded distro’s like FreeNAS or pfSense choose one underlying rock solid base (FreeBSD) and allow easy upgrades including the entire OS via the web UI.[/quote]
That still implies running an dedicated server for FOG. FOG is just some software that needs to be packed for the some of the ditros out there and that flaky installer dropped. Concentrate on the core business, please. -
[quote=“Adrian Zaugg, post: 18233, member: 3427”]I will love to have another server with another distro I have to learn again. And I am sure it will save a lot of time to the FOG developpers… No sorry, wrong way.[/quote]
Im prolly missing what you all mean by distro, but I am reading this as:
the FoG team pre-package a running fog install on Ubuntu 13.10 (or watever).OPTION 1
I download the new FoGuntu (FuBuntu, FogBuntu etc etc) as an ISO.
Install FogTu on new PC.
During install, fog asks a few questions (IP address, pretty much the current questions)
BAM. You have a running Ubuntu distro with Fog running.OPTION 2
Download an appliance. (An already sorted VM of the above.)Adrian Zaugg if youre already using Ubuntu, you wont need to “learn” anything else.
Or have I misread this?
The words “wrong way” are probably not the most accurate choice, as there isnt a wrong or right way for anyone do anything in these areas. Id say the Fog Devs can do what they want, and if we like it, we will use it…one man’s “right” way is another man’s taboo.
Its good you have strong opinions tho, keep up the active participation!
-
[quote=“drjam, post: 18414, member: 16842”]Im prolly missing what you all mean by distro, but I am reading this as:
the FoG team pre-package a running fog install on Ubuntu 13.10 (or watever).[/quote]If you read it as pre-packaging, then it is what I would call the right way. The contributers above wrote something from a distro like pfsense. A distro is not just packaged for a distro.
FOG should not make an asumption on what Linux- or *nix-System it will run, then there are many admins out there, that have this or another distro preference, some use Solaris or *BSDs. To release a distro for FOG also means, to have a dedicated machine for it, or you aren’t no more free to chose your beloved system.
Also it should be up to the admin to chose if in his scenario a dedicated machine does the job, or if it will run on an existing server, which does already other things. FOG is not a firewall, which should be on a dedicated machine. Also it should be up to the admin if he wants to have it in VM or not. With the suggestion of a distro or appliance you cut one or another of the ways to run FOG for an admin. This is in my opinion wrong.[quote=“drjam, post: 18414, member: 16842”]
The words “wrong way” are probably not the most accurate choice, as there isnt a wrong or right way for anyone do anything in these areas. Id say the Fog Devs can do what they want, and if we like it, we will use it…one man’s “right” way is another man’s taboo.[/quote]
Basically yes, but as it would be stupid and thus wrong to let pfsense run as a service on your internal auth and file server it is stupid and superfluous to bloat FOG to an appliance. The temptation of an appliance is it’s easyness of installation. But imagine apt-get install fog… (or rpm, emerge or whatever). If FOG is well prepared for packaging, it is not a big deal no more to do it for the different distros. -
However, it wouldn’t hurt having FOG as a distribution package (think .deb, .rpm) rather than having to maintain its own install script. But hey, let’s have more people on board to do that
I’m actually thinking about having it packaged, so that we can just do apt-get install fog, but there are many other issues to be fixed, and the 0.33 version to be worked on first…Cheers
Gilou -
I was referring to someone making a TurnKey Linux Patch
Fair enough but, I agree on a .deb / .rpm but would also require package maintainers.
Maybe the current approach of install via script is still the correct path for now and allows maximum flexibility.
On a slightly different topic, what are you guys thoughts on the Windows Agent?
What if, FOG server was made to be compatible with the Fusion Inventory Agent instead, and change the entire SFX deployment over to the Fusion/OCS deployment method.
Pros are you already have people developing this agent seperately, once the initial headache of making FOG compatible is over then the devs can focus on other areas and not the Agent.
The biggest benefit is the improved inventory capabilities, rather then with the current FOG where you are required to boot linux to gather inventory, fusion/ocs will be collecting updated inventory all the time.
The downsides are from what I can tell fusion doesn’t install printers like FOG does (does anyone actually use this and not GPO?)
all other portions of the FOG agent can then be replaced with fusion inventory.
/ot Anyone know if Fusion Inventory can display toast notifications in windows 8?
thoughts?
-
hmm, that’s not stupid, the OCS thingie, as it’s anyway probably usually used in such environments where FOG is interested, but can you make the ocs agent report to, and be setup via FOG easily?
Anyway, afaict, the FOG service works quite nicely… -
Can this Fusion Inventory Agent join AD, with the same ease of use, etc? I know that is a loaded question, but I could not find an easy answer on Google.
I do not mean to keep beating a living horse here, but I really think that some kind of AD integration is crucial to the system, overall. I understand that many folks do not use AD, or even Windows, but one of the main reasons I have stuck with this platform (Windows, AD, FOG) is the integrated “auto-naming”, “auto-joining” capabilities - I know that there are many, many alternatives to this system, but I have never seen one in action that works so damn well, and is so user (and entry-level tech) friendly! I just have a hard time contemplating switching to another way of doing this that is LESS good and MORE complicated, like so many of the alternatives out there…
Also, I totally agree about the [I]“Multi-Site improvements and site replication built in with no mods” - [/I]I forgot to mention that in my previous post, and that would just be great!
Thank you for reading,
D.L. -
Completely agree with you on the AD part, that’s the best drawcard to the Windows Agent!
However,
Since the computer naming component is no longer done via the Windows Agent in 0.33b as far as I know its done during the init image process.
Joining the domain could then be done as part of sysprep (as the name would already be right by this stage) thus making that part a moot point.
The only issue from then on, in order to rename the PC, a re-image would be required in FOG, unlike the windows agent which would just rename it, although then a domain re-join is required. How often does this scenario happen though? just re-image it!
Pretty sure OCS/FusionInventory has no such capabilities, it’s just for detailed inventory and software deployment