Bugs in FOG 0.33
-
All,
I was able to get printerAssoc to load from the group fields. However, that being said, the printer’s don’t load to the hosts. This is a bug I’m currently looking into. Hopefully I’ll be able to report back soon.
-
I figured out the problem and was able to tidy up my code to be way more inline with Blackout’s original. I’m still working on the default printer part, so when I figure that out I’ll push the updates, everything else, for now, is working.
-
I’m going to push updates for HostManagementPage, GroupManagementPage, PrinterManagementPage, SnapinManagementPage, and Host.class.php and Printer.class.php and fog.host.edit.js
Edited fog.host.edit.js to allow the checkbox for default printer function similar to radio button. I just think a checkbox is more appropriate as we’re choosing which printer is default.
Though the field is there, as a checkmark, the default value is not set yet.
Found the issue with adding a printer in Printer.class.php that affected Host.class.php in that Printer was requiring name, port, id, and model, which isn’t true when the printer is of network type, it only requires name and id, and if it’s iPrint, it only requires name, port, and id. This allows the addPrinter() function to work properly.
Also corrected the snapin and printer portions of Host.class.php to only insert one instance of a printer. You shouldn’t be able to put 4 of the same printer on a system, and now you can’t on the management system.
Will post in a few minutes.
EDIT: r914 is up (913 updated fine, but I had an unintentional edit on another file)
-
Ur doing some fantastic work tom going to pull down r914 and have a play.
-
Finally, after how many day’s of working with Host Printers (notice not printer management) I finally got default printer’s figured out, though I’m sure it’s not how it was intended. Default Printers, IMHO should be up to the host to manage, so I created two new method’s in the Host.class.php file that Updates/Gets Default printers for that host. I don’t know, and probably won’t try, to get this done on the group side. As long as the group has the printers, that’s what truly matters right? I’ll post update tomorrow.
-
Hi,
Firstly thanks for all the hard work on this, 0.33 seems to be coming along nicely!
I’m currently playing about 0.33B Rev 925 on Ubuntu 12.04, and the Plugin Management page isn’t working yet. When you click ‘Activate Plugin’ (or ‘Installed Plugin’) you get:
[B]“FOG DEBUG: FOGPageManager: Class: PluginManagementPage, Method: activate, Error: Method not found in class, defaulting to index()”[/B]
I noticed a previous post about the same issue a few pages back, but doesn’t seem like anyone responded. Is anyone working on a fix for this yet? The capone plugin is a massive help for me and I’d love to give it a run in 0.33.
Thx/Br
LA -
How is it that you get to the Plugin Management page? I know I should probably know that, but I don’t see even a menu option for that.
Am I missing something, or are you going to the link directly via:
[url]http://<FOGIP>/fog/management/index.php?node=plugin[/url]
With that, I didn’t even notice that part of the process and Am seeing what you’re referring to. I don’t know the original intent of this class but will take a look into it.
-
In the dashboard go to FOG Configuration > FOG Settings
Under the ‘Plugin System’ heading, change the FOG_PLUGINSYS_ENABLED option from 0 to 1 and hit save. You should then see a cog icon in the dashboard that links to the plugin page.
It’s when you click the Installed or activate plugin links the error pops up.
Thanks/Br
LA -
Gotcha. See Even I don’t know everything
-
Added the methods for the installed and activate screens. They don’t do anything, yet and I don’t quite know what they’re supposed to be doing, but I will look into it over this weekend, okay?
-
yeah sure no worries, thank you!
Thanks/Br
LA -
I think the only “plug-in” for FOG right now is Capone.
-
Capone should now be, sort of, operational. Plugins are back from what I can tell. Again, as I’ve never used them, I haven’t really got a clue. I got it functioning within the DB, but I can’t tell if it’s functioning after that point.
r927 out.
Hopefully it’s all good.
EDIT: Had to create a class, but forgot to initially add it to the last commit action. It’s up now. r928
-
Hi,
I spotted a bug on the Image edit page, here’s a diff, but it’s just the path not being displayed (it tries to get $_POST[‘file’] which probably comes from a bad copy/paste). Also, the heading was wrong (add, instead of edit image definition).I have a feeling the host edit page has some inconsistency as well…
[CODE]Index: ImageManagementPage.class.php
— ImageManagementPage.class.php (révision 975)
+++ ImageManagementPage.class.php (copie de travail)
@@ -240,7 +240,7 @@// TODO: Put table rows into variables -> Add hooking ?>
-
<h2><?php print _("Add new image definition"); ?></h2>
-
<h2><?php print _("Edit image definition"); ?></h2> <form method="POST" action="<?php print $this->formAction; ?>"> <input type="hidden" name="add" value="1" /> <table cellpadding="0" cellspacing="0" border="0" width="100%">
@@ -248,7 +248,7 @@
<tr><td><?php print _(“Image Description”); ?></td><td><textarea name=“description” rows=“5” cols=“65”><?php print $Image->get(‘description’); ?></textarea></td></tr>
<tr><td><?php print _(“Storage Group”); ?></td><td><?php print $this->FOGCore->getClass(‘StorageGroupManager’)->buildSelectBox($Image->get(‘storageGroupID’)); ?></td></tr>
<tr><td><?php print _(“Operating System”); ?></td><td><?php print $this->FOGCore->getClass(‘OSManager’)->buildSelectBox($Image->get(‘osID’)); ?></td></tr>-
<tr><td><?php print _("Image Path"); ?></td><td><?php foreach($this->FOGCore->getClass('StorageNodeManager')->find() AS $StorageNode){if($StorageNode->isMaster()){print $StorageNode->get('path');}} ?><input type="text" name="file" id="iFile" value="<?php print $_POST['file']; ?>" /></td></tr>
-
<tr><td><?php print _("Image Path"); ?></td><td><?php foreach($this->FOGCore->getClass('StorageNodeManager')->find() AS $StorageNode){if($StorageNode->isMaster()){print $StorageNode->get('path');}} ?><input type="text" name="file" id="iFile" value="<?php print $Image->get('path'); ?>" /></td></tr> <tr><td><?php print _("Image Type"); ?></td><td><?php print $this->FOGCore->getClass('ImageTypeManager')->buildSelectBox($Image->get('imageTypeID')); ?></td></tr> <tr><td colspan=2><center><input type="submit" value="<?php print _("Update"); ?>" /></center></td></tr> </table>
[/CODE]
Cheers
GIlou -
-
Yeah, lib/pages/HostManagementPage.class.php checks if the hostname already exist… But obviously, if I’m editing it, it obviously exists hehe… too tired to fix, but that’s not cool, it requires a name change every time I update a host
-
I will look into that, sorry!, it’s more for if the name is being changed.
-
Should be fixed with r976 build, both of these things.
-
r977 release,
Should address wrong image type setting for capone if using that plugin.
-
Error in installation script (CentOS 6.5). When installing on a brand new setup I get an error at line 239: confirmPackageInstallation: command not found. Also error Failed to start NFS Server and setupFreshClam (had to manually install DAG repository to install htmldoc and clamav, but clamav seams to fail on Centos.
-
Not sure about the confirmPackageInstallation error, I’ve seen that issue, though it’s cause no real problems. It seems like, for some reason, it’s not calling sourcing the right file. This is fine by itself, though as it’s only the process that confirms if a package has installed.
NFS Server issues shouldn’t be an issue, though it’s probable because of when I had to fix the database issue. Centos checks if the packages mysql, mysql-server, and php-mysql are installed and if they’re not, it checks for mariadb, mariadb-server, and php-mysqlnd, I think it’s here that we’re seeing the confirmPackageInstall error.
To fix the NFS issue, perform:
[code]service rpcbind restart; service nfs restart[/code]
Then try again. It should be fine.I’ve not tested 6.5, but for clamav to install properly, it needs the elrepo packages, not the dag packages, verify that this is the case!