SVN BUGS
-
Couple small ones…
The createdBy database fields are currently being populated with session details or something (“O:4:“User”:25:{s:24:“inactivitySessionTimeout”;i:1”), when it used to be the username. If this isn’t intended, it’s in FOGController.class.php. FOG_USER -> FOG_USERNAME on lines 60 and 61.
PrinterManager.php, the newline is being encoded when it shouldn’t on line 35. Also, empty printers are returned because the $Printers variable is being reused. The results from PrinterAssociationManager get saved to it, then when $Printers is iterated, the printer objects are added. When $Printers is iterated the second time, the PrinterAssociationManager info tries to print (comes up empty) as well as the actual printer info.
-
I’m not sure if this is the same issue but after adding a printer, I am unable to edit it using the webgui. I can go into the database and change the properties there. The GUI does not seem to work well with printers currently. I am also unable to add the printer to groups. The webgui says that it worked, but looking at the hosts assigned printers after shows that it did not assign.
Thanks!
-
SVN 1852 should fix both of these bugs.
Thank you,
-
Working. Thanks!
-
A Wake task still requires an image, which honestly it shouldn’t.
-
[quote=“need2, post: 30716, member: 21891”]A Wake task still requires an image, which honestly it shouldn’t.[/quote]
SVN 1880
Removed need of image setting unless task type is specifically an imaging task (Download, Upload, Multicast, etc…)
-
Received a database error from the web GUI schema update while upgrading to SVN 1880 from 1.1.1 . I did not see a specific error, so here is the output:
See attached.
EDIT: So now I’m stuck in a limbo of sorts. I can’t get past the schema update. I’ll keep fiddling.
When the following is entered manually:
[CODE]Update ID: 1 - 10Database Error:
Database SQL:
INSERT INTO
fog.usersVALUES (‘’,‘fog’, MD5(‘password’),‘0000-00-00 00:00:00’,‘’)[/CODE]I get:
[CODE]Column count doesn’t match value count at row 1[/CODE]
[url=“/_imported_xf_attachments/1/1023_schema_output.txt?:”]schema_output.txt[/url]
-
You restarted mysql service?
-
Yes, that did not do anything for it. There appears to be either a problem with a table or a command being fed to that table.
-
Is this still occurring?
-
Yes, I still can’t get past the schema update step.
-
Okay,
Do me a favor, check your error logs for mysql.
In ubuntu (centos doesn’t have them that I’ve seen) it’s under:
/var/log/mysql/mysql.err or something liek that.Can you try these steps in conjunction with a reinstall? It sounds like mysql just isn’t running.
[url]https://github.com/mastacontrola/fogproject/issues/1[/url] -
As far as I can tell, MySQL is running. It just doesn’t like some part of the schema update. The .log and .err files appear to be empty when viewed by nano. I also did a partial uninstall (deleted everything except my DB and images) and reinstall, and still got stuck on the schema update.
I have now reverted back to 1.1.1, and everything is working normally, but I cannot test the fixes introduced in the newer revisions.
-
[quote=“need2, post: 30856, member: 21891”]As far as I can tell, MySQL is running. It just doesn’t like some part of the schema update. The .log and .err files appear to be empty when viewed by nano. I also did a partial uninstall (deleted everything except my DB and images) and reinstall, and still got stuck on the schema update.
I have now reverted back to 1.1.1, and everything is working normally, but I cannot test the fixes introduced in the newer revisions.[/quote]
So it’s quite possibly a bug I entered, but that doesn’t sound right that “reverting back” fixed the problem. How did you revert back? Just download and re-run installer? or Did you just place backup sql dump?
-
Since the database never appears to have been successfully modified by the installer, I just reran the 1.1.1 installer after deleting all of the FOG pieces except images and the database.
-
I also received the same SQL error(s) when installing SVN 1880. Using fresh installs of the fog, when it prompts for Install/Update SQL data base, it always fails with 20/30 different sql fails (a cascading fail). It fails even with a database upgrade.
I am seeing a lot of warnings like this in my httpd/error_log.
[CODE]PHP Warning: mysqli::escape_string(): Couldn’t fetch mysqli in /var/www/html/fog/lib/db/MySQL.class.php on line 247[/CODE]
There are allot of references to MySQL.class.php in the error_log.
[CODE] PHP Warning: MySQL::sqlerror(): Couldn’t fetch mysqli in /var/www/html/fog/lib/db/MySQL.class.php on line 180, referer: http://192.168.1.4/fog/commons/schemaupdater/index.php[/CODE]Nothing out of the ordinary in mysqld logs.
-
Found and hopefully fixed in 1882, thanks for reporting.
-
Thanks Tom. Your not going to believe this, the timezone thing is back. I’m seeing this over and over in the logs;
[CODE][Thu Jun 19 18:24:11.832481 2014] [:error] [pid 26346] [client 192.168.1.4:38335] PHP Warning: date_default_timezone_get(): It is not safe to rely on the system’s timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone ‘UTC’ for now, but please set date.timezone to select your timezone. in /var/www/html/fog/commons/system.php on line 26, referer: http://192.168.1.4/fog/commons/schemaupdater/index.php[/CODE] -
1884 released.
Trying another approach to default setting timezone.
We’re going to force it to UTC so logs don’t complain. -
I wonder if we shouldn’t complain the PHP maintainers. A warning like that should not get dumped into logs unless verbosity is really high. Besides, which is more ‘dangerous’. Trusting the system’s timezone with or date_default_timezone_get() or forcing a programmer to fix it to UTC just to avoid an overzealous warning?
