[SOLVED] Help with Ubuntu + MySQL

[SgtSpike]

I installed Ubuntu on a VPS, and then installed LAMP.  After a few issues were sorted, everything seemed to be running fine.  I restarted the server several times without any problems.

Then, I go to access my website this evening, and it seems to be having trouble.  I thought it was something wrong with the VPS, so I restarted the server.  Now MySQL won't start up, even though it is listed in the /etc/init.d/ folder.  I even tried starting it manually with "service mysql start", which just seems to lock up the SSH session (it doesn't bring me back to the prompt after typing that).

Any ideas what's going on here?  If I type "ps -e", it shows apache2 running, but not mysql.

[1715495710]

1715495710

[1715495710]

1715495710

[Xenland]

I installed Ubuntu on a VPS, and then installed LAMP.  After a few issues were sorted, everything seemed to be running fine.  I restarted the server several times without any problems.

Then, I go to access my website this evening, and it seems to be having trouble.  I thought it was something wrong with the VPS, so I restarted the server.  Now MySQL won't start up, even though it is listed in the /etc/init.d/ folder.  I even tried starting it manually with "service mysql start", which just seems to lock up the SSH session (it doesn't bring me back to the prompt after typing that).

Any ideas what's going on here?  If I type "ps -e", it shows apache2 running, but not mysql.

What is your specs? possible you don't have enough ram.

[SgtSpike]

512MB of ram... I'll have to check how much is actually being used atm.

[Xenland]

512MB of ram... I'll have to check how much is actually being used atm.

If your just running apache + mysql then you should be alright. But if you are trying to run apache + mysql + bitcoind + pushpoold... you need atleast 756MB for the memory spikes for about 1-5 workers.

[SgtSpike]

512MB of ram... I'll have to check how much is actually being used atm.

If your just running apache + mysql then you should be alright. But if you are trying to run apache + mysql + bitcoind + pushpoold... you need atleast 756MB for the memory spikes for about 1-5 workers.

Just apache + mysql + bitcoind.  I looked, and mem usage is only 14%.  I don't think that is the issue here...

[Xenland]

what happens when you....

Code:

/etc/init.d/mysqld restart

[SgtSpike]

what happens when you....

Code:

/etc/init.d/mysqld restart

Well, mysqld doesn't work, but changing that for mysql gets me this:

Code:

Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service mysql restart

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the restart(8) utility, e.g. restart mysql

But same result - it's not bringing me back to the # prompt.  It's just kind of stuck now, and won't do anything no matter what I type until I reconnect.

[BCEmporium]

After a starting failure do:

tail /var/log/mysql.err

and check what's cooking with MySQL

[SgtSpike]

After a starting failure do:

tail /var/log/mysql.err

and check what's cooking with MySQL

After relogging into SSH, I tried that... nothing shows when I type that command.  It just pulls up another prompt.  After looking at what the command does, I pico'd into the .err file, and nothing is there.  Is there another file I should check?  These are the files in the /var/log/ directory:

Code:

apache2          dbconfig-common  kern.log        messages.1      syslog.2.gz
apparmor         debug            kern.log.1      messages.2.gz   syslog.3.gz
apt              debug.1          kern.log.2.gz   mysql           syslog.4.gz
aptitude         debug.2.gz       landscape       mysql.err       syslog.5.gz
aptitude.1.gz    dist-upgrade     lastlog         mysql.log       syslog.6.gz
auth.log         dmesg            lpr.log         mysql.log.1.gz  syslog.7.gz
auth.log.1       dmesg.0          mail.err        mysql.log.2.gz  udev
auth.log.2.gz    dmesg.1.gz       mail.info       mysql.log.3.gz  ufw.log
boot             dmesg.2.gz       mail.info.1     mysql.log.4.gz  user.log
boot.log         dmesg.3.gz       mail.info.2.gz  mysql.log.5.gz  vsftpd.log
btmp             dpkg.log         mail.log        mysql.log.6.gz  vsftpd.log.1
btmp.1           dpkg.log.1       mail.log.1      mysql.log.7.gz  vsftpd.log.2
ConsoleKit       faillog          mail.log.2.gz   news            wtmp
daemon.log       fontconfig.log   mail.warn       pycentral.log   wtmp.1
daemon.log.1     fsck             mail.warn.1     syslog
daemon.log.2.gz  installer        messages        syslog.1

[BCEmporium]

try:

tail /var/log/syslog

after a MySQL start failure.

[SgtSpike]

Edited the IP's to hide them, but each different series was a different number in the log.

Code:

Aug  2 14:56:27 111-111-111-111 postfix/smtpd[13487]: disconnect from 222-222-222-222.dynamic.hinet.net[222.222.222.222]
Aug  2 14:59:47 111-111-111-111 postfix/anvil[13491]: statistics: max connection rate 1/60s for (smtp:222.222.222.222) at Aug  2 14:56:26
Aug  2 14:59:47 111-111-111-111 postfix/anvil[13491]: statistics: max connection count 1 for (smtp:222.222.222.222) at Aug  2 14:56:26
Aug  2 14:59:47 111-111-111-111 postfix/anvil[13491]: statistics: max cache size 1 at Aug  2 14:56:26
Aug  2 15:03:33 111-111-111-111 dhclient: DHCPREQUEST of 111.111.111.111 on eth0 to 555.555.555.555 port 67
Aug  2 15:03:33 111-111-111-111 dhclient: DHCPACK of 111.111.111.111 from 444.444.444.444
Aug  2 15:03:33 111-111-111-111 dhclient: bound to 111.111.111.111 -- renewal in 16846 seconds.
Aug  2 15:09:01 111-111-111-111 CRON[15086]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)
Aug  2 15:17:01 111-111-111-111 CRON[16044]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug  2 15:39:01 333-333-333-333 CRON[18656]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)

This was the state of tail /var/log/syslog both before and after doing another /etc/init.d/mysql restart.

[BCEmporium]

Try to run this command directly in the console:

/usr/bin/mysqld_safe

(it's the starting command for MySQL-server)

[SgtSpike]

Try to run this command directly in the console:

/usr/bin/mysqld_safe

(it's the starting command for MySQL-server)

Not sure what you mean by "directly in the console".  This isn't a gui version of ubuntu.  All I have is SSH and VNC to the same view.  They should both be the same once logged in, right?

Anyway, I tried said command in the SSH window.  Now we're getting somewhere...

Code:

root@111-111-111-111:~# /usr/bin/mysqld_safe
110802 16:22:23 mysqld_safe Logging to syslog.
110802 16:22:23 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
110802 16:22:24 mysqld_safe mysqld from pid file /var/lib/mysql/111-111-111-111.pid ended

Similarly, the syslog now has:

Code:

Aug  2 16:22:23 111-111-111-111 mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql
Aug  2 16:22:24 111-111-111-111 mysqld_safe: mysqld from pid file /var/lib/mysql/111-111-111-111.pid ended

[BCEmporium]

SSH without GUI is "directly in the console".
So, MySQL started without issues manually. Is it running now?

[SgtSpike]

No, it is not running.

I thought

Code:

Aug  2 16:22:24 111-111-111-111 mysqld_safe: mysqld from pid file /var/lib/mysql/111-111-111-111.pid ended

meant that the process stopped running?

[Bitsky]

You could try starting it with --verbose to see if it spits out more errors.
Also, tail -f /var/log/mysql.log from another login.
Take a look into /var/log/mysql/, perhaps something interesting is in there.

If everything else fails, you can rename your database directory (/var/lib/mysql) and uninstall mysql completely. Don't forget to delete configs like /etc/my.cnf too. Then install it again and see if it's starting. If it does, stop mysql and copy your databases from your renamed directory back in. If it then fails, your database(s) are broken and you need to check/repair them.

If you run anything bad like a "control panel" that relies on mysql you may break your admin panel (which wouldn't be bad, since you only need ssh anyway).

[SgtSpike]

Ok, I tried starting mysql_safe with --verbose.  It didn't seem to change what was output.

I didn't tail mysql.log from another login, since the file has remained empty.  Seems pointless?  Maybe I'm missing something there...

I took a look inside /var/log/mysql/ and noticed an error.log file.  The lines from the most recent run attempt say this:

Code:

110802 17:41:43 [Note] Plugin 'FEDERATED' is disabled.
110802 17:41:44  InnoDB: Started; log sequence number 0 44233
110802 17:41:44 [ERROR] Can't start server: Bind on TCP/IP port: Cannot assign requested address
110802 17:41:44 [ERROR] Do you already have another mysqld server running on port: 3306 ?
110802 17:41:44 [ERROR] Aborting

110802 17:41:44  InnoDB: Starting shutdown...
110802 17:41:45  InnoDB: Shutdown completed; log sequence number 0 44233
110802 17:41:45 [Note] /usr/sbin/mysqld: Shutdown complete

Hmmm... so something is using or binding that port, yet MySQL is NOT already running.  

Gawd, this would be so simple on a Windows box too.  If only it had the security of Linux...

EDIT:  I'm going to google around for an answer to the port problem, but if anyone has more suggestions, feel free to chime in.  Thanks for the help so far guys! 

[Bitsky]

Well mysql seems to be pretty clear about the possible problem: seems like something is already using the port 3306.

Try "netstat -tunap | grep 3306" to see what program it is. Use the pid from that to do a "ps -aux | grep PID" and see more.

From there on, you can decide if you just want to kill -9 whatever process is clinging to the port. Maybe a zombie.

[SgtSpike]

Yikes!  Figured out the issue... turns out, my my.cnf file did not have 127.0.0.1 as the bind-address.  I had changed it in an effort to be able to remotely access the database with MySQL Workbench (which proved to be unsuccessful), then promptly forgot I had made the change.  On the next serve reboot, it took the change, and disallowed local access in the process.

Changed the bind-address back to the local IP, and it's working perfect now.

Community help + googling found the problem, so I thank you all for your assistance.

[BCEmporium]

Just a tip, don't bind MySQL to 0.0.0.0, it has no protection at all against brutte-forcing, rather create a XML or JSON RPC to filter and output data between servers.

[SgtSpike]

Just a tip, don't bind MySQL to 0.0.0.0, it has no protection at all against brutte-forcing, rather create a XML or JSON RPC to filter and output data between servers.

I was hoping I could bind it to a specific external IP address (mine), but also still have it accessible from the localhost.  Evidently not.  All it would have been for is convenience, so I can live without that.  Thanks for the heads up on 0.0.0.0 though.

[Bitsky]

You can bind mysqld to an IP of your server, or to all. Then lock down the port 3306 in iptables (of course you already firewalled your server, right?) and then whitelist your IP. If you have a static IP it's simple; if not, get a dyndns entry and put together a little bash script which adjust your firewall rules every x minutes.

Or learn using the mysql shell directly; there's no need for a remote management tool at all. Then you can lock mysqld down on localhost only.

[SgtSpike]

You can bind mysqld to an IP of your server, or to all. Then lock down the port 3306 in iptables (of course you already firewalled your server, right?) and then whitelist your IP. If you have a static IP it's simple; if not, get a dyndns entry and put together a little bash script which adjust your firewall rules every x minutes.

Or learn using the mysql shell directly; there's no need for a remote management tool at all. Then you can lock mysqld down on localhost only.

I haven't installed or tweaked the firewall beyond whatever is default in Ubuntu, no.  Probably something I should do.    I don't have anything important on the server yet though.  But thanks for the advice.

My IP isn't static, but it has only changed once in the last 10 months.  I guess losing all access if my IP changed would be a bad thing though. 

[Bitsky]

Lock down everything and only allow the ports you really need (eg 80) to be accessed from the outside. You could allow ssh if you switch to public-keys and disable password auth. Of course it would be better to restrict that too, but that way you can still ssh in if you don't want to go the dyndns route if your IP changes. You can also use something like fail2ban too.

[SgtSpike]

Lock down everything and only allow the ports you really need (eg 80) to be accessed from the outside. You could allow ssh if you switch to public-keys and disable password auth. Of course it would be better to restrict that too, but that way you can still ssh in if you don't want to go the dyndns route if your IP changes. You can also use something like fail2ban too.

So allowing SSH from any IP is unsafe, despite having a secure password?  Why?

I do have VNC access, so perhaps I could use that as the failsafe if my IP changed.

I'll look in to fail2ban as well, thanks for the suggestion.

[Bitsky]

So allowing SSH from any IP is unsafe, despite having a secure password?  Why?

Passwords can be sniffed.

Who needs access via ssh? Only you? Good, then why allow everybody to connect? Leaving it open (with key-auth only) can be an acceptable trade-off if you don't want to end up locked out. However, that should be the last choice. Of course, everything else adds a little work, but security isn't free.

Bascially security goes like this: lock down everything. Then open what you need, but only as much as required. VNC isn't really neccessary if you have set up your ssh correctly. In the worst case you'd need a DC monkey to disable your firewall temporarily.

[SgtSpike]

So allowing SSH from any IP is unsafe, despite having a secure password?  Why?

Passwords can be sniffed.

Who needs access via ssh? Only you? Good, then why allow everybody to connect? Leaving it open (with key-auth only) can be an acceptable trade-off if you don't want to end up locked out. However, that should be the last choice. Of course, everything else adds a little work, but security isn't free.

Bascially security goes like this: lock down everything. Then open what you need, but only as much as required. VNC isn't really neccessary if you have set up your ssh correctly. In the worst case you'd need a DC monkey to disable your firewall temporarily.

Considering who the VPS is rented from, I won't rely on them for immediate assistance.

Sounds like I have a lot to work on with the firewall then. 

[BCEmporium]

Passwords can be sniffed.

And here starts the BS... SSH is an encrypted connection like SSL.
There's no issue in have SSH open, you may need to access it from somewhere else outside your home or from a different device. Just keep a good and strong password; crypt is also slow enough to make brutte-forcing not worth the while.

[SgtSpike]

Passwords can be sniffed.

And here starts the BS... SSH is an encrypted connection like SSL.
There's no issue in have SSH open, you may need to access it from somewhere else outside your home or from a different device. Just keep a good and strong password; crypt is also slow enough to make brutte-forcing not worth the while.

Thanks for the clarification.  I thought that was the case, but still know little enough that my knowledge is easily swayed.

How can I tell if the VNC connection is encrypted?  I just use RealVNC (enterprise edition).

[BCEmporium]

I don't use or recommend VNC. It's known for several weaknesses and buffer-overflow attacks. I would stop that thing, as SSH is much safer and does the same.

(but that's a personal hate, as the only time I got a server "hacked" was due to VNC - RealVNC 4 at the time - a stack overflow attack allow someone to bypass the password and access that PC. Hopefully it only had some eMule downloads - mp3 and stuff alike)

[SgtSpike]

I don't use or recommend VNC. It's known for several weaknesses and buffer-overflow attacks. I would stop that thing, as SSH is much safer and does the same.

(but that's a personal hate, as the only time I got a server "hacked" was due to VNC - RealVNC 4 at the time - a stack overflow attack allow someone to bypass the password and access that PC. Hopefully it only had some eMule downloads - mp3 and stuff alike)

Interesting.  I will minimize use of VNC then.

[Bitsky]

And here starts the BS... SSH is an encrypted connection like SSL.

- you can do a downgrade attack on ssh connections
- on a compromised box, the attacker can patch sshd to dump your password

[BCEmporium]

And here starts the BS... SSH is an encrypted connection like SSL.

- you can do a downgrade attack on ssh connections
- on a compromised box, the attacker can patch sshd to dump your password

- Theories... try to put that in practice (good luck)
- Under such the server is already compromised, there's no reason to sniff the password, as that is an "attack from inside out".

There's no way to sniff SSH connections, the only attack surface is the MiM attack and even so the attacker have to gather the key negotiation packet and use it within a really short time frame before the server and client renegotiate the key. "Theoretically" MiM attacks works, in practice they don't. Never come to see anybody got hacked that way when using SSL (including internet banking).

[Bitsky]

- Theories... try to put that in practice (good luck)

Enough reason for me to drop password authentication.

- Under such the server is already compromised, there's no reason to sniff the password, as that is an "attack from inside out".

Of course there is. Do you have any idea how many use the same password over and over again, "because it's so convenient having to remember only one"?

Long story short: I will always tell users to use key based auth. There is no reason to use password auth anymore. Plus, it renders brute-force/dictionary attacks useless.

[SgtSpike]

- Theories... try to put that in practice (good luck)

Enough reason for me to drop password authentication.

- Under such the server is already compromised, there's no reason to sniff the password, as that is an "attack from inside out".

Of course there is. Do you have any idea how many use the same password over and over again, "because it's so convenient having to remember only one"?

Long story short: I will always tell users to use key based auth. There is no reason to use password auth anymore. Plus, it renders brute-force/dictionary attacks useless.

I'm not paranoid.  If an attack only exists in theory, then I'm not going to go out of my way to prevent it.  Especially when it costs me convenience (i.e., not being able to access the server from any computer).  That said, I still appreciate your input on the matter.

I only use that password for root - nothing else.  There is no reason for someone to brute-force that password if they are already in the system.

[Bitsky]

I'm not paranoid.  If an attack only exists in theory, then I'm not going to go out of my way to prevent it.  Especially when it costs me convenience (i.e., not being able to access the server from any computer). 

Using keys has nothing to do with being able/unable to access ssh from a remote computer. Controlling that access level is done via iptables. If the remote user is allowed to go through, then he has to authenticate to ssh. Either via key or password (and actually, keys are more convenient because you can use your public key on different machines).

I only use that password for root - nothing else.  There is no reason for someone to brute-force that password if they are already in the system.

That wouldn't require a brute-force; just a patched sshd because it received the password you typed in. A patch would make it dump that into a file, or mail it somewhere or whatever. But it's good you don't re-use passwords.

That said, I still appreciate your input on the matter.

I'm just pointing things like that out because I have to deal with people who do not think about security.

[BCEmporium]

- Theories... try to put that in practice (good luck)

Enough reason for me to drop password authentication.

So switch off your computer RIGHT NOW! And don't even think about switch it on again... as there's always a "theory" by where you may get attacked. Even using key-auth, your key can get compromised.

- Under such the server is already compromised, there's no reason to sniff the password, as that is an "attack from inside out".

Of course there is. Do you have any idea how many use the same password over and over again, "because it's so convenient having to remember only one"?

Long story short: I will always tell users to use key based auth. There is no reason to use password auth anymore. Plus, it renders brute-force/dictionary attacks useless.

That's an issue of who does that... you won't change that by paranoia.
Same as above, if your key get compromised (yes, your computer can be "hacked/rootkited/get infected") your advice is pointless.

That wouldn't require a brute-force; just a patched sshd because it received the password you typed in. A patch would make it dump that into a file, or mail it somewhere or whatever. But it's good you don't re-use passwords.

Again; if you install a "patched" (infected) sshd it's even stupid that the "patcher" need your password to whatsoever. That said, with that done the attacker can hook to your console and perform whatever he wants. That line of though is like if a robber was already inside the vault and you were concern about the doorstep.

[Bitsky]

So switch off your computer RIGHT NOW! And don't even think about switch it on again... as there's always a "theory" by where you may get attacked. Even using key-auth, your key can get compromised.

I made a note so I won't forget to laugh about it this weekend. When enough jokes have accumulated that is.

Again; if you install a "patched" (infected) sshd it's even stupid that the "patcher" need your password to whatsoever. That said, with that done the attacker can hook to your console and perform whatever he wants. That line of though is like if a robber was already inside the vault and you were concern about the doorstep.

That line of though is like if a robber was already inside the vault through the window and grabs the key you use with all your other vaults.

Let's just leave it at that. We're obviously having different ways to think about security. I've had several cases where my "paranoia" protected servers from a 0day attack.

[BCEmporium]

And I'd invaded servers where the admin was so paranoiac about some services whereas leave others way less safe open or often they put themselves down alone, blasting resources out of needless really long-shot attacks... Paranoiacs are usually a security hole not a solution.
I'm a supporter of NLS and simplicity. If I've to point something at SgtSpike's setup is about have VNC and SSH, because that's two things for the same end.
NLS is a better way to think because attacks aren't linear either, so, unless you want to keep running after patches (and be screwed if you don't get update within time) keep betting in "Linear Security Measures" and "Accountable Security". 

On my "good admin" side, just got that VNC exploit I stated earlier and a list where I gave the key to the user with u:p admin:admin telling him to change it, but he decided "admin:admin" was a good combo to memorize and never changed it... can't tell was all my fault thus, either way from there on I started to handle it with generated passwords and no such linear username as "admin".

[SgtSpike]

I'm not paranoid.  If an attack only exists in theory, then I'm not going to go out of my way to prevent it.  Especially when it costs me convenience (i.e., not being able to access the server from any computer). 

Using keys has nothing to do with being able/unable to access ssh from a remote computer. Controlling that access level is done via iptables. If the remote user is allowed to go through, then he has to authenticate to ssh. Either via key or password (and actually, keys are more convenient because you can use your public key on different machines).

I guess I don't understand the point of authenticating with a key vs a really long complicated password.  Aren't they both effectively the same thing?  And if I authenticated with a key, I would need a keyfile, right?  Which would require that I keep a keyfile on my person whenever I wanted to access the server, whereas right now, I have the password almost memorized (a few more entries should do the trick).

[Bitsky]

I guess I don't understand the point of authenticating with a key vs a really long complicated password.  Aren't they both effectively the same thing?  And if I authenticated with a key, I would need a keyfile, right?  Which would require that I keep a keyfile on my person whenever I wanted to access the server, whereas right now, I have the password almost memorized (a few more entries should do the trick).

You would generate a private/public key pair and place the public key on the server. The private key (which should be protected with a passphrase) stays on your PC. When you log in, no password will ever be transferred. The more servers you have, the nicer it is. As long as your pubkey is on it, you can log in with your passphrase. I wouldn't want to carry around 2-3 pages of passwords to do my daily work. Just store your private key along with your portable Bitcoin in a Truecrypt container on your usb stick.

[SgtSpike]

I guess I don't understand the point of authenticating with a key vs a really long complicated password.  Aren't they both effectively the same thing?  And if I authenticated with a key, I would need a keyfile, right?  Which would require that I keep a keyfile on my person whenever I wanted to access the server, whereas right now, I have the password almost memorized (a few more entries should do the trick).

You would generate a private/public key pair and place the public key on the server. The private key (which should be protected with a passphrase) stays on your PC. When you log in, no password will ever be transferred. The more servers you have, the nicer it is. As long as your pubkey is on it, you can log in with your passphrase. I wouldn't want to carry around 2-3 pages of passwords to do my daily work. Just store your private key along with your portable Bitcoin in a Truecrypt container on your usb stick.

So it's a bit like having a password protected by a password then?

I don't carry a USB stick with me... nor do I carry pages of passwords with me.  I won't go into details about my methods of saving them here though.

Guess it's just one of those different strokes for different folks thing.  As long as the password isn't transmitted in plaintext for an SSH session, then I don't see why it wouldn't be a perfectly secure way of accessing a server.

[BCEmporium]

Actually his method is one password, after one password and then one password.  

Pass#1: To open your truecrypt container
Pass#2: PK password.
Pass#3: Your remote login. (optional, as the key pair can perform auth on their own, but you might want to su to other account)

Because he is a "security guy", probably he is using one of those password managers/generators. Which means that if you get his PC and manage to get and brutteforce his "password manager" along with his PK, you get all in one place to enter on every place he can. Surplus! Because there's no way he can remember (in the braincells) the user/pass combos he has in his password manager, you can just delete its database to lock the owner outside of his own property.
(Isn't paranoia b-e-a-u-t-i-f-u-l or what?)

[SgtSpike]

Actually his method is one password, after one password and then one password.  

Pass#1: To open your truecrypt container
Pass#2: PK password.
Pass#3: Your remote login. (optional, as the key pair can perform auth on their own, but you might want to su to other account)

Because he is a "security guy", probably he is using one of those password managers/generators. Which means that if you get his PC and manage to get and brutteforce his "password manager" along with his PK, you get all in one place to enter on every place he can. Surplus! Because there's no way he can remember (in the braincells) the user/pass combos he has in his password manager, you can just delete its database to lock the owner outside of his own property.
(Isn't paranoia b-e-a-u-t-i-f-u-l or what?)

Lol, I think I'm gonna have to side with you on this one.    I do appreciate having both of your opinions on the matter though.

[Bitsky]

@BCEmporium
You really think I'll go down to that level of yours now? You win, you're the greatest. If that gets you off, I'm glad I could help. 

[BCEmporium]

Believe that "paranoia" and general impractical "security" isn't security, at the best it counts as a nag, isn't "going down" anywhere.

Engineering is all about allocate the appropriate means and measures to a specific desirable end. NO MORE NO LESS! You don't see airplanes made of paper nor planes made of steel.