freddy333

I applaud your hard work. It shows. But, with this level of sophistication, you NEED a camera with a macro feature &/or to work on your picture taking skills. These pics do little to show off details. My only real complaint about the watch is that the datewheel font looks more pink than red, which spoils the overall effect of an otherwise very competent project.

Ditto.

They just do not make them like they used to (& should again).

The end result looks super. Nicely done.

Thank you.

Ending the work week wearing my beater

Wore 1 of the DJs today

I would agree with most of the previous comments, but with the result being less objectionable to my eye. Were it mine, I would have a watchmaker disassemble and sell the obviously genuine parts - movement, crown, caseback, bracelet (though it is incorrect for this case) & hands (probably genuine, but need better macro pics to be sure)). The mid-case may also be genuine, but it may be for a different model. Or, if you decide to keep it (I would) & can afford to put some money into it, source more accurate (genuine or good aftermarket) dial, mid-case & bezel/insert & have a watchmaker properly service & assemble it into a really nice vintage watch

Wearing Goldie around the Ponderosa this morning (but may change to beater this afternoon)

With a gen or good aftermarket dial, handset, movement & crown, a nice aftermarket case like this 1 should pass the test.

Wearing my beater today

I have both 193.201.224 and 193.201.224. (with & without the tailing .) Correct. The allow from all is located after all the deny lines. Because it is 50k in size & contains thousands of blocked IPs, I do not want to post it online. Yes, exactly. If I could afford to upgrade everything, I would. But I cannot. We are using a database, but there are a number of scripts we need & these usually cause problems after upgrades, which causes me to spend many days working to get them going again. I do not have the time now to commit days to fixing everything after upgrading, which is why we are running old hardware/software....it works.

It is not the errors that I am asking about. I just want to figure out why some (not all) IPs are able to access our web server after they have been added to the .htaccess deny lines? As of this morning, the problem is continuing with the same range of Ukrainian IPs (193.201.224). Based on what they are doing, it appears to be the same person, but they are being logged with last part of their IP being different. Unfortunately, I have not kept up on my Unix administration skills & the guy who was handling this left. If I had enough current experience or the money to pay someone, we would definitely upgrade both the OS and hardware (both are several years old). But, other than this very recent .htaccess issue with these Ukrainian IPs, both servers are running well & neither has experienced an access problem in the nearly 20 years of operation. But the continuing accesses by these Ukrainian IPs are very concerning.

We're running apache1 and there is this entry in the error_log for 1 of the IPs (I have replaced a portion of the IP with xxx since this is posted publicly) that are supposed to be blocked - [sat Jul 26 00:00:01 2014] [notice] Apache/1.3.33 configured -- resuming normal operations [sat Jul 26 00:00:01 2014] [notice] Accept mutex: flock (Default: flock) [sat Jul 26 00:01:03 2014] [error] [client 193.150.xxx.xx] client denied by server configuration: /usr/home/triumphpc/public_html/footer.shtml [sat Jul 26 00:01:03 2014] [error] [client 193.150.xxx.xx] unable to include "../footer.shtml" in parsed file /usr/home/triumphpc/public_html/exam/exam.shtml [sat Jul 26 00:01:04 2014] [error] [client 193.150.xxx.xx] client denied by server configuration: /usr/home/triumphpc/public_html/footer.shtml [sat Jul 26 00:01:04 2014] [error] [client 193.150.xxx.xx] unable to include "../footer.shtml" in parsed file /usr/home/triumphpc/public_html/exam/exam.shtml [sat Jul 26 00:01:05 2014] [error] [client 193.150.xxx.xx] client denied by server configuration: /usr/home/triumphpc/public_html/footer.shtml [sat Jul 26 00:01:05 2014] [error] [client 193.150.xxx.xx] unable to include "../footer.shtml" in parsed file /usr/home/triumphpc/public_html/exam/exam.shtml Both the IP (193.150.xxx.xx) and the range (193.150.xxx) are on one of the deny lines in our .htaccess, yet they keep getting in. Any ideas?

If a banned IP re-enters via a proxy or vpn, the originally banned IP should not show up again. But that is what is happening, so I do not think they are using a proxy/vpn. Somehow, our .htaccess has stopped working. So, if there isn't a hack way around it, we must have entered something (an incorrectly formed IP) that is causing the .htaccess file to be non-functional.

No, BSD & until just recently, .htaccess has been 100% effective in blocking any IP or range added. Either I added something incorrectly (typo) that caused it to stop working or there is some new hack (I am not aware of) that allows people to bypass it.

My server. Nothing has changed on it between the time the .htaccess was actively blocking whatever IPs/ranges I added & now.

I have had hundreds of IPs/ranges per line for the past 15+ years & it worked fine. I will try removing the files tags & see how that goes.

Anyone know why my .htaccess has stopped blocking IP addresses? I have been using the same .htaccess on my BSD/Apache web server for many years & I have always been able to block unwanted IP addresses using it. But, recently, although nothing has changed on the server (no hacker break ins), denied IP addresses are getting through. I have tried blocking entire ranges, which has also previously worked, but neither is working now. Can anyone familiar with Unix Apache web servers tell me if they see what might be causing the problem?