FOG Status
-
[SIZE=15px][FONT=Arial][COLOR=#000000]Hello everyone, [/COLOR][/FONT][/SIZE]
[B][/B]
[COLOR=#000000][FONT=Arial][SIZE=15px]So it has been a while since we have released anything any FOG updates and many of your are wondering what’s going on, so I thought an update was in order. [/SIZE][/FONT][/COLOR]
[B][/B]
[COLOR=#000000][FONT=Arial][SIZE=15px]Like many of you, my time has become constrained so the amount of time I have been able to dedicate to version 0.33 has been less than it should be. Peter Gilchrist did an awesome job filling in and helping out with getting the UI closer to where it should be. What we have been stuck on for a little while has been EFI/GPT support, which is important with Windows 8 and modern PCs. Much of this has been an issue with a lack of hardware to effectively test on. There is a little bit more UI work that needs to be done before we can release 0.33, but the biggest issue has been EFI, so if anyone is knowledgeable in this area and would like to help us out we would be grateful! Once we tackle EFI, we should be able to release soon afterwards. [/SIZE][/FONT][/COLOR]
[B][/B]
[COLOR=#000000][FONT=Arial][SIZE=15px]FOG has a couple issues that have been ignored and not really addressed. I am talking about the issues with security, feature bloat, coupling of systems, and an aging code-base. [/SIZE][/FONT][/COLOR]
[B][/B]
[COLOR=#000000][FONT=Arial][SIZE=15px]In terms of security, there are a number of issues that need to be addressed. One obvious issue is the fact that anyone can mount the NFS volumes, as they don’t use authentication. There are numerous other issues as well including the “service” scripts not using any authentication either which is problematic. [/SIZE][/FONT][/COLOR]
[B][/B]
[COLOR=#000000][FONT=Arial][SIZE=15px]FOG initially grew quickly in terms of features to it own detriment. I believe we have a number of features that should not be included in the core release of FOG as they are becoming difficult to maintain. A few of these that come to mind include ClamAV and many of the advanced tasks like file recovery, testdisk, and password reset. Many of the features within the Windows service are no longer functional with Windows 7 and up, but I will discuss the Windows service in more detail later. [/SIZE][/FONT][/COLOR]
[B][/B]
[COLOR=#000000][FONT=Arial][SIZE=15px]FOG relies on many operating system specific features, which I believe it no longer has to. FOG is tightly coupled with tftpd, nfs, and to a lesser degree isc dhcp server. This makes it difficult for FOG to run on other operating systems like Windows or even other Linux distributions. It also makes FOG fragile to changes in the underlying systems, often when a new Ubuntu LTS is released something breaks with FOG. [/SIZE][/FONT][/COLOR]
[B][/B]
[COLOR=#000000][FONT=Arial][SIZE=15px]Lastly, the thing that has been bothering me for a while is the aging code-base. The code was poorly written in the first place and we have just kept adding to it. Peter has helped clean up the code, but in my opinion we are still putting lipstick on a pig. [/SIZE][/FONT][/COLOR]
[B][/B]
[COLOR=#000000][FONT=Arial][SIZE=15px]So here is what I would like to see. First off, I would like to get some community help with EFI/GPT, and get 0.33 out the door. No surprises here.[/SIZE][/FONT][/COLOR]
[B][/B]
[COLOR=#000000][FONT=Arial][SIZE=15px]Then I would like to change things up a bit. I would like to form two or three teams, one that would maintain the UI, and at minimum another to maintain the Linux init image and kernel. I would like to then either discontinue the Windows service (since we can change the hostname via the init image now) or move it to another team.[/SIZE][/FONT][/COLOR]
[B][/B]
[COLOR=#000000][FONT=Arial][SIZE=15px]After this I would like to throw away the currently version of FOG and do a rewrite, it is about that time. As part of the rewrite here are my goals:[/SIZE][/FONT][/COLOR]
[B][/B]
[LIST]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px]Write a custom tftp server into the server. This will allow for improved security, less dependence on the underlying OS, and potential for scaling out more easily. [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px]Drop NFS and replace it with HTTP. This will improve security and cut the dependence on the underlying OS. [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px]Make FOG run on any OS. [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px]Move services like ImageReplicationService and Multicast service into the core context. This also helps reduce the dependence on the underlying OS. [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px]Improve security in general, https out of the box, only serve images that have active tasks, etc. [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px]Pair down the feature set to something more manageable. [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[*][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]
[B][/B]
[COLOR=#000000][FONT=Arial][SIZE=15px]With all this being said, the next thing that needs to get done is support for EFI/GPT as Windows 8 and current PCs pretty much make this a requirement. If we can figure out EFI, I think we can get things back on track. So my questions to the community are do you think we can build the teams I described? Do you know anyone that would be interested in working on the init/kernel side of things? Any other general thoughts, suggestions? [/SIZE][/FONT][/COLOR] -
plas plas plas (cheers)
I’m so glad you wrote this post. I think it was necessary that the project developers expose to where you want to go and why they take so long to get a final version and their goals.
I will give my opinion about some points:
[quote=“Chuck Syperski, post: 13088, member: 4”]
[COLOR=#000000][FONT=Arial][SIZE=15px]FOG initially grew quickly in terms of features to it own detriment. I believe we have a number of features that should not be included in the core release of FOG as they are becoming difficult to maintain. A few of these that come to mind include ClamAV and many of the advanced tasks like file recovery, testdisk, and password reset. Many of the features within the Windows service are no longer functional with Windows 7 and up, but I will discuss the Windows service in more detail later. [/SIZE][/FONT][/COLOR]
[/quote]If some features are obsolete or don’t work under the new OS (like W7 or W8), remove them. If one final user tests FOG and their “tools” [COLOR=#000000][FONT=Arial][SIZE=15px](like file recovery, testdisk, and password reset) and see that they don’t work, then he will say: “The product is not completely good. The product is good, and deploy images well, very well but their “tools” are trash”[/SIZE][/FONT][/COLOR]
[COLOR=#000000][FONT=Arial][SIZE=15px]The EFI/GPT support is really a big problem. And we/you/the commnity must solve it.[/SIZE][/FONT][/COLOR]
[COLOR=#000000][FONT=Arial][SIZE=15px][/SIZE][/FONT][/COLOR] -
I wish I could help in someway, but I am no developer by any stretch of the imagination.
I would however implore you to not kill off the windows service. It is highly important that as a part of the imaging process FOG still be able to rename computers AND join them to the domain (including placing them into the correct OU). Having to do this manually would increase deployment time dramatically.
-
[quote=“Fernando Gietz, post: 13095, member: 13”]plas plas plas (cheers)
I’m so glad you wrote this post. I think it was necessary that the project developers expose to where you want to go and why they take so long to get a final version and their goals.
I will give my opinion about some points:
If some features are obsolete or don’t work under the new OS (like W7 or W8), remove them. If one final user tests FOG and their “tools” [COLOR=#000000][FONT=Arial][SIZE=15px](like file recovery, testdisk, and password reset) and see that they don’t work, then he will say: “The product is not completely good. The product is good, and deploy images well, very well but their “tools” are trash”[/SIZE][/FONT][/COLOR]
[COLOR=#000000][FONT=Arial][SIZE=15px]The EFI/GPT support is really a big problem. And we/you/the commnity must solve it.[/SIZE][/FONT][/COLOR]
[/quote]
Is EFI really such a big problem? This([url]https://wiki.ubuntu.com/UEFI/PXE-netboot-install[/url]) suggests that it is relatively simple to get PXE working on EFI by using GRUB to chainload the linux image.I might be able to help some with the FOG development. I have for example a fully working configuration for the kernel and init.gz that has full support for RAID(Including software raid). The init.gz configuration also uses the newest buildroot to compile.
-
[quote=“Chuck Syperski, post: 13088, member: 4”][SIZE=15px][FONT=Arial][COLOR=#000000]Hello everyone, [/COLOR][/FONT][/SIZE]
[COLOR=#000000][FONT=Arial][SIZE=15px]So it has been a while since we have released anything any FOG updates and many of your are wondering what’s going on, so I thought an update was in order. [/SIZE][/FONT][/COLOR]
[COLOR=#000000][FONT=Arial][SIZE=15px]Like many of you, my time has become constrained so the amount of time I have been able to dedicate to version 0.33 has been less than it should be. Peter Gilchrist did an awesome job filling in and helping out with getting the UI closer to where it should be. What we have been stuck on for a little while has been EFI/GPT support, which is important with Windows 8 and modern PCs. Much of this has been an issue with a lack of hardware to effectively test on. There is a little bit more UI work that needs to be done before we can release 0.33, but the biggest issue has been EFI, so if anyone is knowledgeable in this area and would like to help us out we would be grateful! Once we tackle EFI, we should be able to release soon afterwards. [/SIZE][/FONT][/COLOR]
[COLOR=#000000][FONT=Arial][SIZE=15px]FOG has a couple issues that have been ignored and not really addressed. I am talking about the issues with security, feature bloat, coupling of systems, and an aging code-base. [/SIZE][/FONT][/COLOR]
[COLOR=#000000][FONT=Arial][SIZE=15px]In terms of security, there are a number of issues that need to be addressed. One obvious issue is the fact that anyone can mount the NFS volumes, as they don’t use authentication. There are numerous other issues as well including the “service” scripts not using any authentication either which is problematic. [/SIZE][/FONT][/COLOR]
[COLOR=#000000][FONT=Arial][SIZE=15px]FOG initially grew quickly in terms of features to it own detriment. I believe we have a number of features that should not be included in the core release of FOG as they are becoming difficult to maintain. A few of these that come to mind include ClamAV and many of the advanced tasks like file recovery, testdisk, and password reset. Many of the features within the Windows service are no longer functional with Windows 7 and up, but I will discuss the Windows service in more detail later. [/SIZE][/FONT][/COLOR]
[COLOR=#000000][FONT=Arial][SIZE=15px]FOG relies on many operating system specific features, which I believe it no longer has to. FOG is tightly coupled with tftpd, nfs, and to a lesser degree isc dhcp server. This makes it difficult for FOG to run on other operating systems like Windows or even other Linux distributions. It also makes FOG fragile to changes in the underlying systems, often when a new Ubuntu LTS is released something breaks with FOG. [/SIZE][/FONT][/COLOR]
[COLOR=#000000][FONT=Arial][SIZE=15px]Lastly, the thing that has been bothering me for a while is the aging code-base. The code was poorly written in the first place and we have just kept adding to it. Peter has helped clean up the code, but in my opinion we are still putting lipstick on a pig. [/SIZE][/FONT][/COLOR]
[COLOR=#000000][FONT=Arial][SIZE=15px]So here is what I would like to see. First off, I would like to get some community help with EFI/GPT, and get 0.33 out the door. No surprises here.[/SIZE][/FONT][/COLOR]
[COLOR=#000000][FONT=Arial][SIZE=15px]Then I would like to change things up a bit. I would like to form two or three teams, one that would maintain the UI, and at minimum another to maintain the Linux init image and kernel. I would like to then either discontinue the Windows service (since we can change the hostname via the init image now) or move it to another team.[/SIZE][/FONT][/COLOR]
[COLOR=#000000][FONT=Arial][SIZE=15px]After this I would like to throw away the currently version of FOG and do a rewrite, it is about that time. As part of the rewrite here are my goals:[/SIZE][/FONT][/COLOR]
[LIST]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px]Write a custom tftp server into the server. This will allow for improved security, less dependence on the underlying OS, and potential for scaling out more easily. [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px]Drop NFS and replace it with HTTP. This will improve security and cut the dependence on the underlying OS. [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px]Make FOG run on any OS. [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px]Move services like ImageReplicationService and Multicast service into the core context. This also helps reduce the dependence on the underlying OS. [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px]Improve security in general, https out of the box, only serve images that have active tasks, etc. [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[][COLOR=#000000][FONT=Arial][SIZE=15px][COLOR=#000000][FONT=Arial][SIZE=15px]Pair down the feature set to something more manageable. [/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR]
[*][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]
[COLOR=#000000][FONT=Arial][SIZE=15px]With all this being said, the next thing that needs to get done is support for EFI/GPT as Windows 8 and current PCs pretty much make this a requirement. If we can figure out EFI, I think we can get things back on track. So my questions to the community are do you think we can build the teams I described? Do you know anyone that would be interested in working on the init/kernel side of things? Any other general thoughts, suggestions? [/SIZE][/FONT][/COLOR][/quote][COLOR=#0000ff][SIZE=4]Here’s my 2 cents…i think all those extra tools [FONT=Arial] like file recovery, testdisk, and password reset should be add-on’s that are available for download sort of like those other kernels that are out there. [/FONT][FONT=Arial][FONT=Arial] It’s cheaper to replace hard drives than to purchase a imaging solution but h[/FONT]ard drive support (advance format & SSD) has to be a goal, i’ve been able to mung a solution together a for those pesky advance format drives but it’s not 100% so i have to replace the drives i can’t image. The security goals are nice but i don’t think they are a necessity, 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=“The Dealman, post: 13190, member: 53”][COLOR=#0000ff][SIZE=4]Here’s my 2 cents…i think all those extra tools [FONT=Arial] like file recovery, testdisk, and password reset should be add-on’s that are available for download sort of like those other kernels that are out there. [/FONT][FONT=Arial] It’s cheaper to replace hard drives than to purchase a imaging solution but hard drive support (advance format & SSD) has to be a goal, i’ve been able to mung a solution together a for those pesky advance format drives but it’s not 100% so i have to replace the drives i can’t image. The security goals are nice but i don’t think they are a necessity, 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]
Thanks for the input regarding snap-ins!
-
Hello everyone,
I’m actually following your project pretty close as I am willing to implement your solution at our enterprise. We operate worldwide ([url]http://linkconsulting.com/default.aspx?idl=2[/url]) and although we are rising and organizing, we have several pc’s/servers that would benefit so much from a solution like this. It’s a fresh perspective on pc cloning, and for that you should hang on to, so that like ZenOSs platform, or nothing like it but even better, you can build a strond world arround it and that not far from here you can also start getting some income for your project.
Keep it on and make this new world come true. You guys have a great product here!
Regards,
Fr. -
Another idea would be to add some [I]role-based access control[/I] ([I]RBAC[/I]) to the next release. I have a fog server at every location and it would be nice to have some role based assignments, i build & manage all the fog servers along with the images. My lower level techs don’t need access to a lot of the areas i that manage, they simply need to register new inventory, image and place devices in fog groups. I would also like to see some auditing along with that RBAC
-
Please stop quoting entire posts that’s not how forums work.
The way I see it FOG does like 3 or 4 things that are completely separate but through no ones fault are so tightly coupled you can’t change anything. I mean fog uses 2 different FTP servers for gods sake.
We need;
[LIST]
[]A server to hand out images.
[LIST]
[]The pxe boot images to service tasks like register or pull down the…
[]Client images
[/LIST]
[]A Boot image
[LIST]
[]Just need to be absolutely tiny
[]Runs on any hardware we can throw it at
[/LIST]
[]Management details
[LIST]
[]key/value store of hostname/MAC address’ for tasks to hook onto
[*]handle multiple fog sites if need be
[/LIST]
[/LIST]
I don’t see why any of those all have to be in one project. FOG should literally just be the easiest way to boot an image across a number of computers to do a task. Pretty much everything else would be better served by making another image and use fog to boot that i.e. file recovery. But that’s up to the user to add the boot image. First thing I do to fog is modify the PXE menu to boot the Ultimate Boot CD and ubuntu.
I’m in the process of trying to write just the features I want with nodejs but I’m not putting in much effort as I’ve no idea how to go about making the linux images boot and write/capture my images made with MDT. If I could choose how the good devs of this project use their time I’d spend it on a flawless boot image. Everything else could be a browser application that talks to a fog-like service which in my opinion the community is better developing/iterating on than using the core devs time.
Now I’m going back to trying to compile a kernel to run on my AMD a8-6500/MSI new build. This post may sound critical but I do think you guys are awesome. If you don’t have a lot of time to work with then above is my suggestion on the least you could possibly do for the most benefit. -
[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.
