NukeSentinel 2.0 RC5 settings no saving

Nuke Soldier Joined: Jul 23, 2004 Posts: 22

Since I can't find a NukeSentinel support site with decent forums, I'll ask here: Why aren't my NukeSentinel 2.0.0 RC5 settings saving? I have the proper .htaccess files, they are completely blank (fulfilling the blank line requirement per the README), and they've all been chmodded to 666. I have tried configuring the path to the root .htaccess in the Sentinel Admin panel various ways, but nothing works. No settings are being saved, so I can't turn on any protection. Can someone PLEASE help me? I really want to secure my site.

Premium Joined: Jul 17, 2003 Posts: 47

If you followed the setup/installation instructions, you should be able to save configuration changes in database tables, not in your .htaccess file.

I suggest you check the official Sentinel support forums at RavenPHPScripts

There you'll find more than decent support.

Nuke Soldier Joined: Jul 23, 2004 Posts: 22

Thanks for the advice on Ravenscripts-- I hadn't heard of that one, so in the future I will go there for Sentinel support (concurrent with your reply, I found out that Raven is actually co-author of Sentinel).
And about Sentinel...I fixed it. It must've been a database issue stemming from the upgrade from RC4 to RC5, because uninstalling it and reinstalling it fixed my problems. I followed the "Upgrade" instructions to the 'T', but I don't think the upgrade script updated the database properly. It works like a champ now (I think-haven't tested it yet b/c I'm afraid of getting banned from my own site--wouldn't know how to "unban" myself w/o site access).
And as for using .htaccess or the database for Sentinel settings-well, I have no idea which method "should" be used. I got .htaccess working, so I'm using that for now, but if you could enlighten me as to the merits of each, I'd be greatful.
Thanks again for the reply.

Premium Joined: Jul 17, 2003 Posts: 47

I'm glad you got it to work. It amazes me that the NSN tools support most, if not all, versions of phpNuke AND provide updates from ALL previous versions at the same time AND have a typically easy-to-use installation script. It is a model to which all developers should aspire.

Actually, the database is used by default. If your server runs Apache AND you choose to set the configuration such that your .htaccess path is defined AND you set the configuration for one or more blockers to use .htaccess, it will add blocked IPs to both your database and the .htaccess file.

Since your server (again, assuming you have Apache) checks the .htaccess file BEFORE allowing access to your website, you can prevent access from specified IPs at the server level. If you do not block at the server level via .htaccess, Sentinel will look at the database to determine which will be blocked.

If you have a high volume site, you might prefer to use the .htaccess since that method will require less effort than having phpNuke via Sentinel check the database.

One disadvantage of using the htaccess is that it adds another layer of complexity to what Sentinel does. If Sentinel doesn't correctly update the .htaccess file, it could cause server errors and prevent all access to your site. I experienced this when manually adding blocked IPs, but I simply edited the .htaccess file and removed the bad characters to correct.

If you don't have a high volume site or you don't feel comfortable editing the .htaccess file (it's pretty straightforward, I think), and you most likely won't need to do so), I'd suggest just using the database (i.e. let Sentinel do the work).

Also, if you ban yourself, you would just need to remove your IP address from the nuke_nsnst_ips table and, if appropriate, the .htaccess file.

Good luck...

Nuke Soldier Joined: Jul 23, 2004 Posts: 22

Thanks, your info is a big help. Now I'll go test my PHPNuke installation, without worrying about being locked out. I have no problems using phpmyadmin to play with the db, I just didn't know what table the blocks are stored in.
thanks again.

Premium Joined: Jul 17, 2003 Posts: 47

If you disable the .htaccess during your testing, that's one less thing you'll need to update after a successful test...