I've spent the past couple of days working on the enable/disable code, in an attempt to get rid of the maint.pl Perl script.
I have something now that I believe works well, so if you feel like trying it out I've generated a patch for you against Hobbit 4.0.2. It is available at http://www.hswn.dk/beta/maintenance-feature.patch
Installing is the usual:
cd hobbit-4.0.2
patch -p0 </tmp/maintenance-feature.patch
make
stop Hobbit
make install (as root)
start HobbitMy solution works somewhat differently than the old "maint.pl" script: The enable/disable functionality is no longer a separate webpage listing all hosts; instead, this function is moved to each hosts' "info" column page. I did this because I have about 2000 hosts, so the list of all hosts was practically unusable in my setup. You can see how it looks on the demo site http://www.hswn.dk/hobbit/ - just pick one of the "info" buttons.
You can of course disable tests (a single one, some of them, or all of them); you can re-enable tests that have been disabled; you can schedule a disable to happen at a later time; and you can cancel scheduled disables if they are no longer needed.
The scheduled disabling is handled internally in the Hobbit daemon, so you no longer need "cron" running to handle it. I've never been fond of allowing my CGI scripts to run at-jobs from a security perspective...
Regards, Henrik
On Thursday 14 April 2005 15:53, Henrik Stoerner wrote:
I've spent the past couple of days working on the enable/disable code, in an attempt to get rid of the maint.pl Perl script.
[snip]
My solution works somewhat differently than the old "maint.pl" script: The enable/disable functionality is no longer a separate webpage listing all hosts; instead, this function is moved to each hosts' "info" column page. I did this because I have about 2000 hosts, so the list of all hosts was practically unusable in my setup. You can see how it looks on the demo site http://www.hswn.dk/hobbit/ - just pick one of the "info" buttons.
The problem with this sollution is, that everybody with acces to the monitorpages can now enable/disable tests. We like to make information available to all IT-staff, but the enabling/disabling is being done by operations, based on RFC and calls. How to prevent others from enabling/disabling in this new concept?
Paul
On Thu, Apr 14, 2005 at 04:31:45PM +0200, Paul van Eldijk wrote:
My solution works somewhat differently than the old "maint.pl" script: The enable/disable functionality is no longer a separate webpage listing all hosts; instead, this function is moved to each hosts' "info" column page. I did this because I have about 2000 hosts, so the list of all hosts was practically unusable in my setup. You can see how it looks on the demo site http://www.hswn.dk/hobbit/ - just pick one of the "info" buttons.
The problem with this sollution is, that everybody with acces to the monitorpages can now enable/disable tests. We like to make information available to all IT-staff, but the enabling/disabling is being done by operations, based on RFC and calls. How to prevent others from enabling/disabling in this new concept?
Everyone can see what's disabled, but using the enable/disable function still requires a separate authorization just like maint.pl does today.
That's why you cannot disable anything on my demo page - unless you can guess what password I use.
Regards, Henrik
Henrik Stoerner wrote:
My solution works somewhat differently than the old "maint.pl" script: The enable/disable functionality is no longer a separate webpage listing all hosts; instead, this function is moved to each hosts' "info" column page. I did this because I have about 2000 hosts, so the list of all hosts was practically unusable in my setup. You can see how it looks on the demo site http://www.hswn.dk/hobbit/ - just pick one of the "info" buttons.
Glad to see this feature! I checked it out and have some comments about what *I'd* like to see, but this may not be what everyone else wants. I'll say it anyway. ;)
I still like having the ability to disable many hosts at once from the same page, using the pull down menu in the tool bar instead of teh info column.
I found it confusing to have both the "disable now" and "schedule disable" buttons right next to each other, and the cause field over the schedule disable.
I want to log a cause for every disable/enable, scheduled or immediate. I'd love to have a form that has separate fields for the comment and a name, so I can some what enforce my local policy of "put your name in the comment field so we know who's doing what on the systems".
Something like this:
Select enable/disable from teh tool bar, go to the
Click on the host(s) & tests you want disabled. Since you have tons of systems and don't want to scroll through all of them, maybe you could have 2 columns, one for the group and the other for the systems in that group.
Be forced to enter both a comment and a user name to track who/what is going on.
Select from a pull down menu if you want this immediately or in the future. if the future is selected, a new set of menus appears that allows you to schedule the start/stop times.
Push an "apply" button and everything goes into effect.
Thats my two cents. Flame away.
Tom
OK, it seemed like most of you liked this new feature, but all of you still wanted a way of disabling stuff on many hosts at once. So I've been busy adding - essentially creating a Hobbit-version of the full maint.pl script.
The result is an updated maintenance-feature patch, available as always from http://www.hswn.dk/beta/maintenance-feature-v2.patch
This is against the 4.0.2 release, like the first version of the patch.
The patch implements the same feature as the first version - you can disable tests for a single host from the "info" page - but it adds an extra script "hobbit-enadis.cgi" that takes over from the maint.pl script. hobbit-enadis.cgi displays an administration page very much like the maint.pl one; I've unashamedly stolen Tom's JavaScript code and used it in my implementation. (I hope he doesn't mind - I'll ask for his permission). However, to better cope with the enormous host-list I've added the ability to filter hosts using three regular expressions - against the hostname, the pagename of the host, and the IP address. That makes it slightly more usable to me...
And:
On Thu, Apr 14, 2005 at 10:35:44AM -0400, Tom Georgoulias wrote:
- I found it confusing to have both the "disable now" and "schedule disable" buttons right next to each other, and the cause field over the schedule disable.
This has been fixed. I think the current display is very intuitive.
I want to log a cause for every disable/enable, scheduled or immediate.
This is now forced via some Javascript validation, which also makes sure you don't hit the "Apply" button without selecting hosts, tests, entering a valid duration etc.
Regards, Henrik
Henrik Stoerner wrote:
First of all, I like the new enadis tool. Thanks for putting out the new, non-perl version so soon.
The patch implements the same feature as the first version - you can disable tests for a single host from the "info" page - but it adds an extra script "hobbit-enadis.cgi" that takes over from the maint.pl script.
This may be a local problem, but after I built hobbit with this new patch in place my old maint.pl remained and the only way I could access the new script was by manually typing in the correct path URL.
hobbit-enadis.cgi displays an administration page very much
like the maint.pl one; I've unashamedly stolen Tom's JavaScript code and used it in my implementation. (I hope he doesn't mind - I'll ask for his permission). However, to better cope with the enormous host-list I've added the ability to filter hosts using three regular expressions - against the hostname, the pagename of the host, and the IP address. That makes it slightly more usable to me...
I like the new enadis page layout much more than the last. However, I do have one comment--there is no easy way to enable several hosts at once, they still have to be done one by one. Can this be changed to allow group enables?
Tom
On Mon, Apr 18, 2005 at 10:51:59AM -0400, Tom Georgoulias wrote:
The patch implements the same feature as the first version - you can disable tests for a single host from the "info" page - but it adds an extra script "hobbit-enadis.cgi" that takes over from the maint.pl script.
This may be a local problem, but after I built hobbit with this new patch in place my old maint.pl remained and the only way I could access the new script was by manually typing in the correct path URL.
"make install" doesn't update the menu-file. Change the ~/server/www/menu/menu_items.js file to link to hobbit-enadis.sh instead of maint.pl
I like the new enadis page layout much more than the last. However, I do have one comment--there is no easy way to enable several hosts at once, they still have to be done one by one. Can this be changed to allow group enables?
The host selection listbox lets you select multiple hosts. Just hold down <ctrl> while you click on the hosts you want to disable.
Regards, Henrik
Henrik Stoerner wrote:
The host selection listbox lets you select multiple hosts. Just hold down <ctrl> while you click on the hosts you want to disable.
Oh, I was referring to enabling them after they've already been disabled. The ones in the "Currently disabled tests" block. They have "enable" buttons next to each host, but no obvious way to do more than one at a time.
Tom
BB would include the URL of the test that caused the alert in the BBALPHAMSG environment variable. Could this be added to hobbit.
FYI - the BBCOLORLEVEL environment variable isn't listed in the on-line documentation (http://www.hswn.dk/hobbit/help/hobbit-alerts.html#scripts).
Thanks,
Paul
On Mon, Apr 18, 2005 at 12:19:46PM -0500, Paul D. Backer wrote:
BB would include the URL of the test that caused the alert in the BBALPHAMSG environment variable. Could this be added to hobbit.
FYI - the BBCOLORLEVEL environment variable isn't listed in the on-line documentation (http://www.hswn.dk/hobbit/help/hobbit-alerts.html#scripts).
Thanks, the attached patch should fix both issues. Save it to a file, then
cd hobbit-4.0.2 patch -p0 </tmp/hobbit-4.0.2-alertscript.patch make
Shutdown hobbit, run "make install" as root, and restart hobbit.
Regards, Henrik
Henrik Stoerner wrote:
OK, it seemed like most of you liked this new feature, but all of you still wanted a way of disabling stuff on many hosts at once. So I've been busy adding - essentially creating a Hobbit-version of the full maint.pl script.
I have a question about the new hobbit-native enable/disable tool, but I haven't had enough time to test it out for myself to know the answer.
One of the downsides to the way the current enable/disable maint.pl works is the way the trend charts do not continue using data collected from clients after the tests are disabled. For example if I disable disk tests for a server, the BB client still sends the data to hobbit and the latest values are displayed, but those values aren't put into the graphs. As a result, I have large blank gaps in spots when a test was disabled. I can understand the presence of these gaps when a client is offline, but if I'm getting the data but just don't want be bothered with pager alerts from a server issue I'm already aware of, shouldn't that be OK?
Tom
On Wed, Apr 20, 2005 at 09:55:59PM -0400, Tom Georgoulias wrote:
One of the downsides to the way the current enable/disable maint.pl works is the way the trend charts do not continue using data collected from clients after the tests are disabled. For example if I disable disk tests for a server, the BB client still sends the data to hobbit and the latest values are displayed, but those values aren't put into the graphs. As a result, I have large blank gaps in spots when a test was disabled. I can understand the presence of these gaps when a client is offline, but if I'm getting the data but just don't want be bothered with pager alerts from a server issue I'm already aware of, shouldn't that be OK?
It should, and I actually thought Hobbit was already working that way. But no - I forgot to send "blue" status reports through to the RRD update routine.
Patch is attached.
BTW, I expect to release a 4.0.3 version over the week-end with the patches that have accumulated, and the new enable/disable tool. Before Lars objects - I think I have found out what why it is hanging for you, so I'll send you a patch later today for testing.
Regards, Henrik
Henrik Storner
Hi Henrik
BTW, I expect to release a 4.0.3 version over the week-end with the patches that have accumulated, and the new enable/disable tool. Before Lars objects - I think I have found out what why it is hanging for you, so I'll send you a patch later today for testing.
Do you also plan to release some day bbgen 3.6 (bbgen 3.5 with the 5 patches available here : http://www.hswn.dk/hobbitsw/bbgen/) ?
Thanks for your answer.
Regards,
--
Frédéric Mangeant
Henrik Stoerner wrote:
It should, and I actually thought Hobbit was already working that way. But no - I forgot to send "blue" status reports through to the RRD update routine.
Patch is attached.
Thanks for the patch. I put it, and all the others from the list (including the new enadis tool) for 4.0.2 into production today. So far everything works as expected. Glad to be free of the maint.pl shortcomings.
BTW, I expect to release a 4.0.3 version over the week-end with the patches that have accumulated, and the new enable/disable tool.
Will the 4.0.3 enadis tool have any new features that aren't already present in maintenance-feature-v2.patch?
My server says hobbit 4.0.3, so I wonder if I'll even need to upgrade to the official 4.0.3 release....
Tom
On Thu, Apr 21, 2005 at 10:55:56AM -0400, Tom Georgoulias wrote:
BTW, I expect to release a 4.0.3 version over the week-end with the patches that have accumulated, and the new enable/disable tool.
Will the 4.0.3 enadis tool have any new features that aren't already present in maintenance-feature-v2.patch?
There are some differences. The hobbit-enadis code that picks up the data when you post an enable/disable request is buggy - it works for most people, but not all.
My server says hobbit 4.0.3, so I wonder if I'll even need to upgrade to the official 4.0.3 release....
Oops - must have missed putting in the "4.0.2m2" version number sometime. I would suggest upgrading, just to be sure that there are no already-solved bugs lurking in your installation.
Regards, Henrik
Henrik Stoerner wrote:
There are some differences. The hobbit-enadis code that picks up the data when you post an enable/disable request is buggy - it works for most people, but not all.
Something else we've noticed after using the new enadis tool is just how big the webpage gets once you disable all of the tests on a handful of systems. Each test for each hosts gets its own block, and if you have 5 or so systems offline, each with all 11 tests disabled, well....the page is just huge. Enabling those systems currently disabled is also a bit more cumbersome than before, since you have to click the enable button for each system.test. Of course you can get around that by going to the info column for a system that you want enabled and select the ALL button, but an equivalent does not exist for the enadis.sh page.
Just my 2 cents.
Tom
On Fri, Apr 22, 2005 at 08:29:15AM -0400, Tom Georgoulias wrote:
Henrik Stoerner wrote:
There are some differences. The hobbit-enadis code that picks up the data when you post an enable/disable request is buggy - it works for most people, but not all.
Something else we've noticed after using the new enadis tool is just how big the webpage gets once you disable all of the tests on a handful of systems. Each test for each hosts gets its own block, and if you have 5 or so systems offline, each with all 11 tests disabled, well....the page is just huge.
I thought about removing the details of each disabled test from the page itself, and just put them in a pop-up window that appears when you let the mouse "hover" above the host.test text.
My current version also by default applies a "page" filter to the enadis page, so it includes only hosts that are present on the page you invoked it from (you can of course clear the filter and get all hosts).
Enabling those systems currently disabled is also a bit more cumbersome than before, since you have to click the enable button for each system.test. Of course you can get around that by going to the info column for a system that you want enabled and select the ALL button, but an equivalent does not exist for the enadis.sh page.
Should it be
- a button to enable all tests for a single host ?
- a button to enable all tests for all hosts ?
- a checkbox so you can check off those host+test combos you want to enable ?
- all of the above ?
Henrik
Hi all
Enabling those systems currently disabled is also a bit more cumbersome than before, since you have to click the enable button for each system.test. Of course you can get around that by going to the info column for a system that you want enabled and select the ALL button, but an equivalent does not exist for the enadis.sh page.
Should it be
- a button to enable all tests for a single host ?
- a button to enable all tests for all hosts ?
- a checkbox so you can check off those host+test combos you want to enable ?
- all of the above ?
I'd like this behavior :
- a button to enable all tests for a single host using hobbit-enadis.sh, as with the "old" maint.pl
- a checkbox to choose any host+test combo using the "info" column, as it is now.
I like the idea of using hobbit-enadis.sh for a "global" view, and the "info" column for a more specific one.
--
Frédéric Mangeant
On Fri, Apr 22, 2005 at 02:52:30PM, Henrik Stoerner wrote:
On Fri, Apr 22, 2005 at 08:29:15AM -0400, Tom Georgoulias wrote:
Henrik Stoerner wrote: Enabling those systems currently disabled is also a bit more cumbersome than before, since you have to click the enable button for each system.test. Of course you can get around that by going to the info column for a system that you want enabled and select the ALL button, but an equivalent does not exist for the enadis.sh page.
Should it be
- a button to enable all tests for a single host ?
- a button to enable all tests for all hosts ?
- a checkbox so you can check off those host+test combos you want to enable ?
- all of the above ?
All of the above.
Also is it possible to send one email per submit instead of per host.service?
In other words if I disable ALL or some services for ALL/Some/One host(s), it would be nice to receive one email per action/submit instead of receiving one email for each host.service.
Old maint.pl used to work like that, means one email only per action and not per host.service
Just a suggestion and not critical
Thanks
-- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu "..there are two kinds of people: those who work and those who take the credit...try to be in the first group;...less competition there." - Indira Gandhi
Henrik Stoerner wrote:
Should it be
- a button to enable all tests for a single host ?
- a button to enable all tests for all hosts ?
- a checkbox so you can check off those host+test combos you want to enable ?
- all of the above ?
Been thinking about this and at the risk of overcomplicating teh interface, I think that all of the above are needed.
My users are more likely to do all their mangement of enabling/disabling hosts from the pull down menu, not the info column. Having full management options available on that page is key to making things simple to remember.
Tom
Henrik,
Do you have plans to add back the username like in the maint.pl? I would like to see who is disabling tests.
conn
Disabled by: unknown @ some.ip.addr.ess Reason: WE can't do anything to resolve this issue
Until: Fri Apr 29 13:53:45 2005
~David
On Fri, Apr 29, 2005 at 02:40:58AM +0000, David Gore wrote:
Do you have plans to add back the username like in the maint.pl? I would like to see who is disabling tests.
conn
Disabled by: unknown @ some.ip.addr.ess Reason: WE can't do anything to resolve this issue
The default setup puts the enable/disable on a webpage that is password-protected, and it then automatically picks up the username you used to login.
If you really want to know who is disabling stuff, perhaps that was worth considering ?
Henrik
Henrik Stoerner wrote:
On Fri, Apr 29, 2005 at 02:40:58AM +0000, David Gore wrote:
Do you have plans to add back the username like in the maint.pl? I would like to see who is disabling tests.
conn
Disabled by: unknown @ some.ip.addr.ess Reason: WE can't do anything to resolve this issue
The default setup puts the enable/disable on a webpage that is password-protected, and it then automatically picks up the username you used to login.
If you really want to know who is disabling stuff, perhaps that was worth considering ?
I suppose I do not know what you mean. I didn't disable anything. I have added a password via Apache for the entire Hobbit site when our security people complained. I cannot say I have see a password request for this specific page.
I will add security for the cgi-secure directory as well, if that is what you mean. It many evoke some complaining about two passwords for hobbit we will see.
~David
Henrik
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
This may be a stupid oversight, but I am confused. I installed hobbit-4.0.2-1 yesterday on a server that was previously running BB. I took down the BB processes, completed the install and brought across my bb-hosts file. For now, I didn't bring across any of the history. Everything runs fine (better actually!), except that I don't get any updates for CPU, disk. memory, messages and processes. The clients are running just as they were before. When I look at the other server which is still running BB, I see the updates coming across the way they should.
The hobbit server was previously configured as a failover BB server, which I never managed to get truly failing over and assuming the BBPAGER role anyway. In my bb-hosts I have both servers defined as BBNET and BBDISPLAY, but only one defined as BBPAGER.
I'd appreciate any pointers on what I'm overlooking. Thanks.
On Fri, Apr 29, 2005 at 09:47:39AM -0400, Allan.Marillier at dana.com wrote:
This may be a stupid oversight, but I am confused. I installed hobbit-4.0.2-1 yesterday on a server that was previously running BB. I took down the BB processes, completed the install and brought across my bb-hosts file. For now, I didn't bring across any of the history. Everything runs fine (better actually!), except that I don't get any updates for CPU, disk. memory, messages and processes. The clients are running just as they were before. When I look at the other server which is still running BB, I see the updates coming across the way they should.
Check the bb-hosts file used by the BB clients - they have their own file, with a definition of which server is the BBDISPLAY server.
The hobbit server was previously configured as a failover BB server, which I never managed to get truly failing over and assuming the BBPAGER role anyway. In my bb-hosts I have both servers defined as BBNET and BBDISPLAY, but only one defined as BBPAGER.
I think your client bb-hosts file has the old BB server listed as BBDISPLAY, instead of the Hobbit server.
You can have both, e.g. if you have the client installed in /usr/local/bb/bbc1.9e-btf/ (the client $BBHOME setting) then in the etc/bb-hosts file you can have
10.0.0.1 bbserver.foo.com # BBDISPLAY BBPAGER
10.0.0.2 hobbitserver.foo.com # BBDISPLAY BBPAGERThe clients will then send their status updates to both servers.
Note: You need to restart the client after changing the bb-hosts file.
Henrik
I checked again just to be sure, but I had already set all clients over a year ago to have both servers listed as BBDISPLAY and BBNET, but only one as BBPAGER. I thought that was all I needed. The hostname and IP address have not changed - all I did was bring BB down on one of the two servers, install hobbit and copy across the bb-hosts and bring hobbit up.
Everything else worked like a dream, except my ssh test, which under BB I had to put in as ssh:s. Under hobbit that kept flipping between yellow (something like an unexpected ssh connect ting I think) and green . Once I removed :s from the ssh test that was also perfect.
henrik at hswn.dk (Henrik Stoerner) 04/29/2005 11:14 AM Please respond to hobbit at hswn.dk
To hobbit at hswn.dk cc
Subject Re: [hobbit] Disk / CPU / memory monitoring
On Fri, Apr 29, 2005 at 09:47:39AM -0400, Allan.Marillier at dana.com wrote:
This may be a stupid oversight, but I am confused. I installed hobbit-4.0.2-1 yesterday on a server that was previously running BB. I took down the BB processes, completed the install and brought across my bb-hosts file. For now, I didn't bring across any of the history. Everything runs fine (better actually!), except that I don't get any updates for CPU, disk. memory, messages and processes. The clients are running just as they were before. When I look at the other server which is still running BB, I see the updates coming across the way they should.
Check the bb-hosts file used by the BB clients - they have their own file, with a definition of which server is the BBDISPLAY server.
The hobbit server was previously configured as a failover BB server, which I never managed to get truly failing over and assuming the BBPAGER role anyway. In my bb-hosts I have both servers defined as BBNET and BBDISPLAY, but only one defined as BBPAGER.
I think your client bb-hosts file has the old BB server listed as BBDISPLAY, instead of the Hobbit server.
You can have both, e.g. if you have the client installed in /usr/local/bb/bbc1.9e-btf/ (the client $BBHOME setting) then in the etc/bb-hosts file you can have
10.0.0.1 bbserver.foo.com # BBDISPLAY BBPAGER
10.0.0.2 hobbitserver.foo.com # BBDISPLAY BBPAGERThe clients will then send their status updates to both servers.
Note: You need to restart the client after changing the bb-hosts file.
Henrik
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
David Gore wrote:
Henrik Stoerner wrote:
On Fri, Apr 29, 2005 at 02:40:58AM +0000, David Gore wrote:
Do you have plans to add back the username like in the maint.pl? I would like to see who is disabling tests.
conn
Disabled by: unknown @ some.ip.addr.ess Reason: WE can't do anything to resolve this issue
The default setup puts the enable/disable on a webpage that is password-protected, and it then automatically picks up the username you used to login.
If you really want to know who is disabling stuff, perhaps that was worth considering ?
I suppose I do not know what you mean. I didn't disable anything. I have added a password via Apache for the entire Hobbit site when our security people complained. I cannot say I have see a password request for this specific page.
I will add security for the cgi-secure directory as well, if that is what you mean. It many evoke some complaining about two passwords for hobbit we will see.
~David
I suppose I do not know how to fix this. The enable/disable doesn't pick up the login for the Hobbit site and I cannot get apache to ask for a second password on the enable/disable page. Perhaps I have the apache config wrong?
Alias /hobbit "/export/home/hobbit/server/www" <Directory "/export/home/hobbit/server/www/"> Options Indexes FollowSymLinks Includes MultiViews Order allow,deny Allow from all AuthUserFile /export/home/hobbit/server/etc/hobbitpasswd AuthType Basic AuthName "Hobbit Network and Application Monitoring" Require valid-user </Directory>
ScriptAlias /hobbit-cgi "/www/hobbit/cgi-bin" <Directory "/www/cgi-bin/hobbit"> AllowOverride None Options ExecCGI Includes Order allow,deny Allow from all </Directory>
ScriptAlias /hobbit-seccgi/ "/www/hobbit/cgi-secure/" <Directory "/www/cgi-secure"> AllowOverride None Options ExecCGI Includes Order allow,deny Allow from all AuthUserFile /export/home/hobbit/server/etc/hobbitpasswd AuthType Basic AuthName "Hobbit Administration" Require user dwgore </Directory>
~David
On Fri, Apr 29, 2005 at 02:14:27PM +0000, David Gore wrote:
I suppose I do not know how to fix this. The enable/disable doesn't pick up the login for the Hobbit site and I cannot get apache to ask for a second password on the enable/disable page. Perhaps I have the apache config wrong?
Alias /hobbit "/export/home/hobbit/server/www" <Directory "/export/home/hobbit/server/www/"> Options Indexes FollowSymLinks Includes MultiViews Order allow,deny Allow from all AuthUserFile /export/home/hobbit/server/etc/hobbitpasswd AuthType Basic AuthName "Hobbit Network and Application Monitoring" Require valid-user </Directory>
ScriptAlias /hobbit-cgi "/www/hobbit/cgi-bin" <Directory "/www/cgi-bin/hobbit">
Is this Directory name correct ? By default, Hobbit puts the cgi directory in the same top-level directory as the "server" directory, so I would expect that to be
<Directory "/export/home/hobbit/cgi-bin/hobbit"> AllowOverride None Options ExecCGI Includes Order allow,deny Allow from all </Directory>
and of course the same change for the cgi-secure directory.
Henrik
On Fri, Apr 29, 2005 at 01:17:29PM +0000, David Gore wrote:
Henrik Stoerner wrote:
On Fri, Apr 29, 2005 at 02:40:58AM +0000, David Gore wrote:
Do you have plans to add back the username like in the maint.pl? I would like to see who is disabling tests.
conn
Disabled by: unknown @ some.ip.addr.ess Reason: WE can't do anything to resolve this issue
The default setup puts the enable/disable on a webpage that is password-protected, and it then automatically picks up the username you used to login.
I suppose I do not know what you mean. I didn't disable anything. I have added a password via Apache for the entire Hobbit site when our security people complained. I cannot say I have see a password request for this specific page.
I will add security for the cgi-secure directory as well, if that is what you mean. It many evoke some complaining about two passwords for hobbit we will see.
As long as you use the same authentication setup for the cgi-secure directory as for the rest of the Hobbit site, your users should not see a second password request - the browser sends it automatically.
Henrik
This small enhancement will put an icon on the location bar of your browser as well as on the tab, if you browser supports tabs (such as Firefox).
First, start by inserting the following HTML tag inside the <HEAD> ... </HEAD> section of each header file in the web directory:
<link rel="shortcut icon" href="&BBSKIN/ico/favicon-&BBBACKGROUND.ico">
Second, and last, unzip the attached file into the www/gifs directory. You should have a ico directory in the gifs directory containing seven files.
That it. The location of the icon files maybe could be somewhere more suitable but this was the easiest for me. The HTML tag maybe doesn't need to be added to every header file, I'm too busy to figure it out. I used the recent.gifs for the icons, if you want others this website, http://www.html-kit.com/favicon/ can convert almost any image into an icon compatible with this process.
Paul
In <1114100868.14206.59.camel at laie> "Paul D. Backer" <pauldb1 at cotepe.carenet.org> writes:
This small enhancement will put an icon on the location bar of your browser as well as on the tab, if you browser supports tabs (such as Firefox).
I like this :-) Added for the next release.
Thanks, Henrik
participants (8)
-
Allan.Marillier＠dana.com
-
David.Gore＠mci.com
-
frederic.mangeant＠steria.com
-
henrik＠hswn.dk
-
iqbala-hobbit＠qwestip.net
-
P.vanEldijk＠uci.ru.nl
-
pauldb1＠cotepe.carenet.org
-
tgeorgoulias＠mcclatchy.com