Problem with Saving Settings - they dont save.

When I try to change some of the required settings in the Required settings section, for example URLbase, it says they are saved at the top of the screen but when I go back in they havent been.. The same holds true for RequireLogin. Any ideas on where I should look?  Where are they are kept?  params file?

I found something interesting - when I go to the data folder I see the params file but it is called params.json.  I also see a whole bunch of .tmp files for example: .tmp.eXTUTNlfTz

I opened a file and it seems to contain all of the params with all of the changes that I made.

My assumption is that for some reason the params file is not being overwritten. Any suggestions on how to fix this?

0 eko 12/30/2020 2:41:06 PM

Editing the params file manually does work as the settings do show up when you go back to look a them but the fact that I dont see any errors concerns me. I am running IIS. Where should I go to check the errors that it may be throwing?  

0 eko 12/30/2020 2:59:28 PM

Use ProcMon again during saving settings and see what it tells you. 

There are most likely some permissions wrong, like adding new files is allowed, deleting existing ones not or alike.

0 windows 12/30/2020 3:06:18 PM

question:  Permissions on what?  The bugs user?

I see the following in the IIS logs:

2020-12-30 14:46:54 192.168.XXX.XXX GET /bugzilla/editparams.cgi section=3Dgeneral 666 - 192.168.XXX.XXX Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/87.0.4280.88+Safari/537.36+Edg/87.0.664.66 http://192.168.XXX.XXX:666/bugzilla/editparams.cgi 200 0 0 2202

2020-12-30 14:47:53 192.168.0.179 POST /bugzilla/editparams.cgi - 666 - 192..168.XXX.XXX Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/87.0.4280.88+Safari/537.36+Edg/87.0.664.66 http://192.168.XXX.XXX:666/bugzilla/editparams.cgi?section=3Dgeneral 200 0 0 2074

2020-12-30 14:47:59 192.168.0.179 GET /bugzilla/editparams.cgi section=3Dadmin 666 - 192.168.XXX.XXX Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/87.0.4280.88+Safari/537.36+Edg/87.0.664.66 http://192.168.XXX.XXX:666/bugzilla/editparams.cgi 200 0 0 1954

2020-12-30 14:48:03 192.168.XXX.XXX GET /bugzilla/editparams.cgi section=3Dgeneral 666 - 192.168.100.200 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/87.0.4280.88+Safari/537.36+Edg/87.0.664.66 http://192.168.XXX.XXX:666/bugzilla/editparams.cgi?section=3Dadmin 200 0 0 1925

2020-12-30 14:48:44 192.168.XXX.XXX POST /bugzilla/editparams.cgi - 666 - 192.168.100.200 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/87.0.4280.88+Safari/537.36+Edg/87.0.664.66 http://192.168.XXX.XXX:666/bugzilla/editparams.cgi?section=3Dgeneral 200 0 0 2032

Does this look correct?

0 eko 12/30/2020 3:34:50 PM

No, the one actually running the Perl files within IIS. However that is configured. I suspect a file system level permission issue.

> I see the following in the IIS logs:
[...]
> Does this look correct?

Yes, it looks like Bugzilla things it successfully replaced the file while it actually doesn't seem to have.

0 windows 12/30/2020 3:50:06 PM

I couldnt see ANYTHING that looked like a rights issue in procmon.  I guess you need to know what to filter and how, not something that I would know.

In any case, you mentioned permissions so I went to the params file and modifed the permissions for Users and Everyone to all permissions.  Works fine now.  

It would be good to know why the permissions werent setup properly by either Bugzilla or by Strawberry or however they needed to be setup.

0 eko 12/30/2020 4:15:59 PM

Strawberry Perl can't know anything about what permissions any executed application needs somewhere. Bugzilla OTOH does care about permissions, but only on Linux/OSIX and even that it doesn't care about ACLs, but only POSIX basic permissions and stuff like that.

In my opinion, apps shouldn't care about permissions at all, that's something admins need to take care of. Remember that you can configure IIS to execute things using different users and stuff like that, that can't easily be known to apps. On Linux/POSIX, checksetup.pl tries to know such things using "localconfig" and configured groups, though.

But Windows is often ignored when such questions arise.

0 windows 12/30/2020 4:28:10 PM

In that case we should be provided with a doc that talks about all of the files that may need permissions to be set. Someone doing a new install, new to bugzilla would NEVER know what needs to be done. Perhaps this is why there are fewer users of the product as it seems the odyssey to configuring it properly is not well documented?

0 eko 12/30/2020 5:12:04 PM

Unlikely, there were never many Windows-users of Bugzilla anyway. :-)

That's the reason for a lack of docs for Windows, people don't care too much. Things are easier and somewhat well documented on Linux, the only problem you would have ran into most likely would have been the problem with "groups" of MySQL. Depending on the used Linux distribution and stuff.

0 windows 12/30/2020 5:43:41 PM