Is there a FOG Service for Linux Clients?
-
Is there a fog service for Linux Clients? If so can you oint me to it?
Thanks
-
Nope
But there could be
-
Gilou is correct.
The windows client is currently being rewritten from scratch. The majority of the modules are done but development has slowed due to the limited free time I have. We do plan on making a fully featured client for osx & linux though but we have no estimates when that would be.
-
Is that work done on SVN ? Is the work still done in C# requiring Visual Studio ?
The best would be to document a bit the API (even if it’s not REST or whatever standard), it should then be pretty easy to do something for Linux. And we need a mailing list, not a forum.
-
Here’s a quick overview of what’s going on / features added (it may give some insight as to why the rewrite is taking awhile).
Please note that everything below is subject to change.
1.) The SVN repository does not contain the new client. The client is developed on a separate branch on our git repository and will be merged with svn when it is ready for beta testing.
2.) While the program is still done in c# for Windows, it is done in a much more light weight, and open source IDE, Sharp Develop. With that said, I have been working on something special recently: the ability to compile a new installer for the client straight from the web portal. (You update the source files, go to the web portal and hit “Compile & Update” which gives you new binaries).
3.) The API is fairly documented as I have re-written everything to be completely modular. Writing custom modules is a cinch. For example, our AutoLogOut module is 67 lines long and our Directory Cleaner module is 39 lines long.
4.) Security has gone through the roof. Currently we have AES 256 encryption options for all traffic but are planning on adding asymmetrical encryption for both the client & server. We would perform client authentication to ensure nothing has been tampered with and if we detect anything the client is blacklisted until it is re authenticated.
5.) There is another experimental feature in the works: event-driven modules. Rather then checking in every X seconds for new tasks an encrypted concurrent connection is formed between the server and client, allowing the server to notify the client of a task immediately. This would allow for instant snapin deployment, cloning, e.t.c. Essentially it makes the client use less cpu on the computer and become more responsive.
6.) One of my favorites. In-place upgrades. If you upload an update file to FOG the clients will download and apply it without needing a reboot.
7.) User-level tasks. We actually run 2 services now. A system-level one for things like installing software and a user-level one for tasks that are user-specific.
Theses changes require a bit of work on both the server and client side. Once everything is finished for windows, porting over to different platforms should be fairly straight forward.
-
Question would be, what is the git repository you are talking about?
And SharpDevelop, might be good if it doesn’t make it impossible for non-windows users to contribute
-
[quote=“Gilou, post: 38849, member: 3221”]Question would be, what is the git repository you are talking about?
And SharpDevelop, might be good if it doesn’t make it impossible for non-windows users to contribute :)[/quote]
I believe he’s referring to this one: [url]https://github.com/mastacontrola/fogproject/tree/fogservice-rewrite[/url]
-
gotcha!
Gonna give it a look, see if I can compile it using mono, and maybe write a PoC in Python for Linux, who knows. -
The service compiles in mono already, that’s actually how we are letting users build the installer from the web ui. As for the linux version I’d advise against making anything relating to the client. We have new api for the client, and are working on reworking how the client and service communicate altogether. Anything that is made is more than likely going to break immediately due to the number of changes being made.
-
Well, if mono can compile it, and compile it for Linux, that might be a “ready to go” situation (where .NET is used “properly” as a multi-platform framework, lol ?), avoiding more development… but it’d rather be working without a web black box, again so as to make sure we can be reasonnably certain there is no dependency on closed source (or un-runnable) things
The only “rich man” concern would then be, will we allow a mono dependency on linux just to run this, but I know I would if it meant no need to worry about it