FOG Status
-
[quote=“Chuck Syperski, post: 13088, member: 4”]
[LIST]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px](Here comes the controversial change, get ready…) Move away from PHP. I don’t do much work in PHP any longer, I don’t want to start a flame war, but there are somethings I love about PHP (ie: it’s a psuedo functional language and FP is good.) but there are also things that I really don’t like about PHP, and those I won’t go into here. I would prefer to rewrite the FOG front-end is a statically typed language like Scala with Play2 potential or even Java (I know I said a bad word).[/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[][/LIST][/quote][LIST]
[/LIST]Just an opinion. If you want help with FOG, how many PHP developers / programmers are out there versus “Scala with Play2 potential” developers? IMHO, if you change away from PHP mid-stream, and have to re-write everything from scratch, you might be setting up the project for failure.
-
Hi,
Just to report how I’m actually using or what I wanted to see :
[LIST]
[]I’m not using third-party boot, neither FOG services (windows APP)
[]I always thought that the Unsecured NFS was The hole in FOG Security
[]EFI/GPT doesn’t concern me now, but it will.
[]Rewriting the whole interface in Scala seems a good idea, but maybe it could wait for the 0.34 as the 0.33 is waited.
[*]The network part should allow multiple FOG network, without need to Route the Cloning data.
[/LIST]
Still, it’s a good project and I really want to see it continue to live.
If there is something I could help with, fell free to contact me.
I’m good at nothing, but prepared to do anything.
Regards,
Panda -
Hi,
We are a heavy user of FOG here (training center, with a few national branches), as probably most of the people that get sucked into using that great project. I did not see this post as soon as I would have liked, but as I was wondering what was going on about 0.33, here I am.
There are selling points that I consider important about FOG. Important as in, it could be made irrelevant if it wasn’t as it is. Those points are :
- easy integration in a Linux environment
- PHP codebase (sort of)
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. You want to run that on Windows? Use the tools Windows provide. You still want FOG, but you don’t know Linux, how about providing an appliance to have it working out of the box? Or anything… But the Linux environment is a great opportunity, and what makes FOG quite friendly (to me, granted… but well.)
You want to transfer 10+ GB images over HTTP ? What ? OK. NFS security issue: granted. The only way to avoid that is to have the write operations done on a separate network (VLAN), petty much. But NFS works quite nicely, is usually really, really easy to setup, and performance is usually quite good. From where I’m sitting, this is an issue I know about, but doesn’t bother me that much. If my PXE infrastructure is used by anyone, it is going to catch fire at some point… I keep backups and don’t use the NFS images mountpoint for anything else, so well.
As for dependencies, and integration in distributions… I wondered why FOG didn’t came packaged for those distribution, now I realize it’s probably because it takes more time that you have on your hands. This can be most certainly tackled by the community. Using .deb or .rpm to avoid the complex, quite buggy installation script would be quite good (and it pretty much boils down to call apt-get, and do some configuration on debian anyway)… The point is, I don’t think you should go away from all the Linux goodness around it: there are things that will make FOG more efficient, focusing on the imaging issues and the kernel, rather than the underlying technologies.
Now the codebase… Cue the flamewars indeed. I don’t like PHP, and I know that the FOG codebase suffers from its legacy… But still… PHP runs easily, and apache is easy to setup… I mean, even by hand, putting FOG at work probably takes less than an hour. If you want to go for trendier language, my advice would be to keep close to what sysadmins usually like, and know how to deploy/hack around. I might sound like an old timer on that, but PHP, or probably more Python would be my first choices. There aren’t many sysadmin tools written in language such as Java or Scala… I’d recommend thinking twice about going there… Even though that might sound anti-progressist… We are talking about a tool running an important piece of infrastructure…
That being said… I’m not a Windows 8 shop, yet, so the UEFI thing is a non-issue for me, as of now. Though working with Apple things might require me to go there… However, I usually boot a live Ubuntu when the FOG kernel can’t do things, and end up sending images “by hand” when I encounter an issue. However, I’m pretty sure I can give in and help with that part. And I agree a separation would make sense, to split the work, between the UI, and the FOG kernel. I sometimes wonder why it is not based off a more common distribution, to ease the configuration / maintenance… But then, most distribution tend to get strongly bloated, when we need something quite light. I would go for some ubuntu/debian, but that’s because I sold my soul to debian…
As for the Windows Service : it was always buggy to me, I would have liked some things, but maybe this can be worked out as an integration with what Microsoft has to offer (unattended stuff) rather than a dedicated utility. So basically, we don’t use it.
And the other features (clamav, stuff, blah), I just never use that… My debug tool is to PXE boot ubuntu, and we generally have other tools for maintenance. Integration with PXE / TFTP here is essential, because FOG doesn’t need to know more about what I want to boot when FOG doesn’t provide what I need. Back to not ditching the linux toolset underneath
Looking forward to helping, if need be.
Cheers
Gilou
-
Gilou et al.
Well said.
I agree that we need to maintain the current setup. If Chuck so decides to make it an individualized application, that’ll be fine and I think we have enough of a community here now that we’d make a fork of the current state of FOG just for familiarity sake, should that not be much of an issue to the original creators.
I love the fact that this system uses linux. If only for the part that we merely need to install the required packages. The current setup allows us a, relatively, painless method of install by using the scripts, but ultimately the script is just used for the simple configuration and installation of packages. If we know which packages are needed, we could conceivably make this less distribution dependent by installing via source. This could also be handy if we have the source setup to install for FOG style file systems on the linux host as it provides a means for a centralized location rather than the standard file system for basic services, such as http, mysql/maria, php, tftp, and NFS.
I understand what you mean when you state NFS is the security hole presently and completely agree, though the current 0.32 and 0.33 still install vsftp as the directory. Why not just use ftp to send the files? My only guess to why we use NFS is because the filesystem can be mounted like a regular disk and information transferred that way. However, we create a fog user on the linux system and setup a password for this user, why not use ftp? It would help close the big hole in allowing anybody to mount and write/delete items from the image store.
I’ve played a bit with gpxe, pxe, and ipxe. I didn’t see much change in loading the bzImage and init.gz file but again I also didn’t try loading an ISO. The idea of integrating gpxe/ipxe into the system is quite nice in that it would, conceivably, allow for cross country imaging and management of systems. You’re not relying upon the idea of keeping the imaging within the same network, you just point to the [url]http://<ip/hostname>/{bzImage,init.gz}[/url] file and the host is loading. Though this method could hurt as it would assume all network cards support gpxe/ipxe by default which they do not. The current method many use over standard PXE is chainloading gpxe with a file called gpxelinux.0 This still boots as regular tftp until the gpxe picks up, then it can point to the http.
I hope we keep the FOG system under the current methods. A web interface to work with is a lot simpler, IMHO, to operating FOG. It allows a method of remote management if configured properly. Basically, I can set tasks up within my network without having to physically be at the location. Going to an individualized application method would kind of thwart that ideology.
I do use memtest and clamav, but I don’t think the current system is feasible. I’d say mount a temporary share and have the server run the clamav system itself. Using the init.gz file to host clamav is a bit cumbersome at best because it rely’s upon the system not updating the actual files running which it does rather frequently. So embedding the init.gz file with A version of clamav may work at first, but after a little while it becomes outdated. Using the server to perform the tasks make a bit more sense and it’s easier to upgrade one system, and you’re not forcing the init.gz system to download (temporarily mind you) the latest signature/virus risks.
-
- I implore you to stick with Linux.
- Not a huge PHP fan. If you must change the language, consider a rapid development environment such as Ruby on Rails (ruby) or Django (python).
- NFS security doesn’t concern me too much. It is easy enough to reduce (not eliminate) risk by configuring the server to allow read-only connections only from specific IP ranges or subnets and read-write connections from specific administrative IP addresses.
- FTP would be fine with me as an NFS replacement. Something like CurlFtpFS could be used to mount the FTP share as a folder and use it just as NFS is currently use, only with password protection.
- I’m not quite sure how you would accomplish certain necessary or convenient tasks without the Windows service/client. Such as rebooting for an image refresh and rename+domain-join. What am I missing here. It seems a client-side service is ONE of the things that makes FOG so flexible and useful. Perhaps it should be rewritten as a VB or Powershell script that could be more easily modified and maintained. Either it runs as a service or it runs as a recurring scheduled task.
-
There’s nothing that fog does that powershell remoting can’t do better when you consider a windows 7+s2008 with winRM installed at a minimum environment. Bonus is security is already done for that. Not having a client application in my opinion is a big win, makes new deployments that bit more friendlier. Using powershell should really be sysadmin 101 and is looking to go more that way every day.
Looking at the wikis for nfs, samba and ftp it strikes me that the problem we have with NFS is that we aren’t using enough of it. Theres all kinds of authentication and multi server load balancing and redundancy etc. we aren’t using. There’s a heck of a lot being added to SMB in the windows world with s2012 and 12r2 is there anything there to look into? Booting multiple machines off a single shared vhdx image file I think is pretty new for 2012 R2.
-
Best thing about Linux is price to performance. No UI means better performance. Webmin if you need it. Free OS, Free tools, Free database. No expensive OS requiring CAL’s with a DBMS requiring CAL’s with a management tool that has to be purchased on top of that. Plus, I’ve used microsoft’s management tools in the past, they market great, and fail to deliver on their promises without weeks of training and years of experience and a support contract so you can call them when you just can’t figure things out.
FOG needs to stay accessible to the masses that have little to no budget for imaging. If we can make headway into the market where people have million dollar budgets, that’s an added bonus.
And there is no enterprise support team for FOG.
-
An another note, I would like to stay with php because the developer base is there already. I would prefer however if the FOG web UI was a templated system with caching, rather than a mixed code/presentation system.
I’ve worked with a few php based systems that have great templating/caching setups that make it really easy to make logic/process changes without affecting the UI, and vice vera.
-
[FONT=Tahoma]First I want to say thank you to everyone who has helped to create and develop FOG. I consider adding FOG to our network as one of the top, if not the top changes we have ever made. We have used PTMagic, Ghost, and ZENWorks in the past, but none of them have been as fast, user friendly, and stable as FOG.[/FONT]
[FONT=Tahoma] [/FONT]
[FONT=Tahoma]Working for a school district with budget cuts at every turn and a do more with less feeling for support gets difficult at times. FOG has filled several holes for us. While our primary use of FOG is imaging of our desktops and our primary inventory source the “other” tasks such as password recovery, disk scanning, memory testing, hostname change (very much so), and even the AV have been very helpful! While we have never gotten to use the snap-ins and printer management I trust others have found them useful.[/FONT]
[FONT=Tahoma] [/FONT][FONT=Tahoma]I hope for the continuing development of FOG as newer operating systems are released and times change. Thank you again to everyone who helps with development![/FONT]
-
[QUOTE]There’s nothing that fog does that powershell remoting can’t do better when you consider a windows 7+s2008 with winRM installed at a minimum environment. Bonus is security is already done for that. Not having a client application in my opinion is a big win, makes new deployments that bit more friendlier. Using powershell should really be sysadmin 101 and is looking to go more that way every day.
[/QUOTE]Careful there, this implies you have a platform to run your powershell thingies, and that you only maintain Windows on the guests…
The reason I use FOG in the first place is to avoid having to maintain Windows Servers for the infrastructure. So FOG does what powershell doesn’t : run an imaging solution based on opensource components. I’m really happy for MS customers that they have those shiny setups included, but it doesn’t make FOG any less relevant. -
[quote=“The Dealman, post: 13190, member: 53”][COLOR=#0000ff][SIZE=4][FONT=Arial] a nice to have item for me would be a better way to do snap-ins. If i had that it would reduce the size of images by far ![/FONT][/SIZE][/COLOR][/quote]
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’?
Because ALL of our software is deployed by snapins. Our windows 7 SOE is around 12GB that includes all driver packs.
:::::::::::::::::::::::
I totally agree with Gilou and Tom Elliot. If you went to the hassle of developing FOG to run off windows server I wouldn’t bother with it. I think one of the reasons it works so well is because it runs on linux, FOG is without doubt the most reliable server we have out of around 100 servers.
IMO FOG doesn’t need a ground up rewrite. FOG does everything so well. There are many additional features like the AV which we don’t use at all, however the main functions are perfect, deploying images and deploying snapins. That’s the core of FOG and it does it well running on linux servers. The web interface is fine IMO. The main thing I think FOG needs is EFI GPT support.
-
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.
