Latest FOG 0.33b
-
r1451 and 1452 released.
Adds an example ltsp.conf file to the src/ipxe/src folder. This is only for the dnsmasq/proxyDHCP guys but this works with the undionly.kpxe information. It’s basically a clone of the Ubuntu WIKI example of ltsp.conf, with the necessary values uncommented and the unnecessary ones commented.
Hope you all enjoy.
-
r1453-55 released.
These releases include a new feature Chuck, and I, think will help those who want to donate to the project, but don’t want to donate in real cash money.
The program included is called darkcoin and it’s a bitcoin mining utility. This has all been setup and configured within the latest init.xz file, and does NOT work in the init_32.xz file yet.
The intention for this inclusion, is during the install process, another question is asked to the user about giving up one of the cores of the system being imaged (during the imaging process only) to assist in the “mining” operation. The default, when asked, will be No and will be totally up to the person installing to allow it in the first place.
The way it will work, is there will be another GUI option added to the FOG Settings to enable/disable this mining utility. A check will be done during the load up of the imaging processes to check if it is enabled or not. If it is enabled, it will boot into the system and start the process to do the mining.
What this allows.
It allows you to “donate” to the FOG Project without actually spending real money. This will be used in assisting the project out with paying for the services such as the web pages and other services required.
Hopefully you all understand. Currently, the files are in the init but there is nothing enabling it right now. I have the configuration and binaries there, but there’s nothing activating it at the moment.
-
As long as it’s the Client system, during imaging, then sounds fine to me.
Do you think it would affect performance if the client only has 1 core? (some of my older PCs have single core CPUs.)
-
I’m probably going to add checking for the number of cores available. As long as there’s more than one, it will work, otherwise leave it alone as one core could potentially cause performance issues.
-
r1457 released.
Fixes a bug in the fog settings and the capone plugin specifically. May need to delete the plugin and readd it, but the plugin stuff will work properly now.
-
r1458 released.
Adds information statement to UserManagementPage about the checkbox. Fixes an issue in the mkdir function of FOGFTP. Updates the bzImage files to 3.14.1.
-
r1459 and 1460 released.
Fixes an issue of multiple MACs sent for the services, if the second mac didn’t exist it was returning as if there were multiple hosts. This is now corrected for. 1460 just sent an invalid host if it wasn’t found in the first place so things still work properly. -
r1461 released.
Fixes an issue of groups being sent.
Also adds the Group tags if List view is defaulted view.
-
r1462 released.
Fixes the search to render properly as well.
-
I re-installed fog today, but I have run into an issue. I had exported the host before uninstalling and when I try to import them back it gives me an error that a Host with this MAC Address already exists. I checked the database and it was empty. I performed a full registration on one of the host that was in the list and it was successful. I tried the import again thinking it might need one in before but it still didn’t work.
-
I believe I found and fixed the issue.
r1467 released should correct this for you.
-
r1468 released.
Fixes the Mobile page host tab so search is there whether or not search is selected as the default view. Fixes an issue on the Hosts where the Group Processing action-box gets displayed on all of the tabs.
-
r1469 released.
Fix so memtest taskings actually operate. You will have to remember to cancel the tasking from FOG or your system will continuously boot into memtest.
-
[quote=“Tom Elliott, post: 25744, member: 7271”]r1469 released.
Fix so memtest taskings actually operate. You will have to remember to cancel the tasking from FOG or your system will continuously boot into memtest.[/quote]
What causes it to continuously run?
-
memtest doesn’t really run in an OS layer, so there’s no way to tell the FOG GUI that it is running, or that it’s finished running. So, unless you manually cancel the task, even if you intend for it to reboot into OS, it will just keep telling that system there’s a memtest task to be performed.
-
r1470 released.
Mining is now enabled within the scripts. It will only start the mining operation under three very specific conditions.
- ) Mining is enabled on the GUI.
- ) The system has more than one core.
- ) The system is an x86_64 bit system.
Hopefully people won’t mind enabling this feature.
-
r1471 released.
With this comes the ability to send a tasking and it will perform the tasking to any registered NIC that tries to PXE Boot. Fixes the Additional MACs so they are actually stored.
-
r1472 released.
Fix the hardware display (link from dashboard) so the information display’s properly. The CPU Speed line was showing the microcode and the cache line was showing the CPU Speed. This has been corrected.
-
I am curious what ports you require for the Mining features for those of us with paranoid firewalls. I may take a box that is on its way out and let it spend its last working hours making you money XD .
EDIT: Is there something I can do to force the machine to stay in this mining mode? If not I could always keep it redoing a task lol.
-
If you look in the conf files you can see the login info for their miner.
Then just install your own and use those credentials.
