Auch ein herzliches Dankeschön an Dich

Danke und ja

54

Sysinternals -> Diskmon

With "lsof .lock" you could check what program holds that file open. If that lists nothing, dig through "ps axu" (as root) and look for a bitcoin related program. Kill it and voila.

Switch to root and when in .bitcoin, do a "cd .." and then "rm -rf .bitcoin"
The directory most likely contains some hidden files, which are not shown with just a "ls"; do a "ls -la" instead.

Some things that come to mind:
- perhaps namcoind has an option to specify the data directory (bitcoin has, I'm using that)
- symlink (ln -s) or hardlink (mount -o bind) those directories (hardlinks need to go into /etc/fstab too iirc)

Hm, can you post the script you use?

Did you get any output when you did the update-rc.d?
Undo the previous: update-rc.d myscriptname remove
Set runlevels manually: update-rc.d myscriptname start 13 stop 06
Look into /etc/rc3.d/ to see if there's a symlink to your /etc/init.d/myscriptname

Logs should go into /var/log/. Usually, there's messages, boot, syslog or something similar which might contain some information about why the service start fails. dmesg perhaps too.
I'm running out of ideas sadly though, since Ubuntu isn't my preferred Linux distro. Oh, and you are in runlevel 3, right? Check with "who -r".

And "/etc/init.d/myscriptname start" works just fine when you do it manually? What user are you when doing that? Root?

Haven't used Ubuntu that often, but if I remember correctly you can have a service start automatically at boot with something like "update-rc.d myscriptname defaults" as root.
Or you can symlink to the script in init.d from rc3.d/S99myscriptname (don't forget that you probably also need to symlink rc1.d/K99myscriptname).
Don't forget to look into logs for error messages.

I thought about something that might be pretty helpful and should be easy to implement: a "waiting for" list.

Basically a list of transaction you're expecting to arrive. You pick the address you gave to the other person and the amount he should transfer to it (perhaps also add a textbox for notes). Transactions which match entries in that list are highlighted. This way you can easily keep track of outstanding transfers. Right now I do that in a seperate textfile, but it would be nice to have that ability in the client itself.

Because the è isn't at the start of the line. Try the haystack 'èggs' and it will match.

Also...

I assume you don't mean "coinfig", but "config"

To capture all output (stdout+stderr), you can append ">> /var/log/bitcoinpool.log 2>&1".
Also, check your standard logs (messages, cron) for additional error messages.

In most cases such scripts fail because of relative paths. Cron has a different environment.

@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. 

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.

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

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.

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).

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.

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

Enough reason for me to drop password authentication.

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.

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

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.