Bitcoin RPM packages for Fedora and Red Hat Enterprise Linux

[Carlton Banks]

~/.config/Bitcoin-Qt.config has the line strDataDir=/home/user/.bitcoin, so my guess is that there's another Bitcoin-Qt.config in either /var/lib/bitcoin or /etc/bitcoin taking precendence. Or something else?

[1715123839]

1715123839

[1715123839]

1715123839

[1715123839]

1715123839

[error]

~/.config/Bitcoin-Qt.config has the line strDataDir=/home/user/.bitcoin, so my guess is that there's another Bitcoin-Qt.config in either /var/lib/bitcoin or /etc/bitcoin taking precendence. Or something else?

See the previous message.

Anyway I've pulled this build as it's exposed an upstream bug that needs to be fixed. For now just do the manual recovery described in #57. And if you happened to install the bad GUI build, run

Code:

yum clean all; yum distro-sync

to back it out.

[Carlton Banks]

Yes, I'd tried the clean and distro-sync.

ringingliberty repo at this moment in time doesn't have the bitcoin package on it, I'm assuming you're aware of that?

[error]

Yes, I'd tried the clean and distro-sync.

ringingliberty repo at this moment in time doesn't have the bitcoin package on it, I'm assuming you're aware of that?

You should be using the bitcoin repo, not the rl repo. I've rebuilt the repodata, try it again.

[Carlton Banks]

Yes, only the bitcoin branch of the repo is enabled on my system. I'm getting:

Downloading packages:
bitcoin-0.9.2.1-2.fc20.x86_64. FAILED                                          
http://linux.ringingliberty.com/bitcoin/f20/x86_64/bitcoin-0.9.2.1-2.fc20.x86_64.rpm: [Errno 14] HTTP Error 404 - Not Found-:-- ETA
Trying other mirror.


Error downloading packages:
  bitcoin-0.9.2.1-2.fc20.x86_64: [Errno 256] No more mirrors to try.


Edit: just tried since your rebuild, same error

[error]

Edit: just tried since your rebuild, same error

You sure you ran

Code:

yum clean all

? The repos look fine now.

[RedDiamond]

[user@bitcoin .bitcoin]$ find Bitcoin-Qt.conf
find: 'Bitcoin-Qt.conf': No such file or directory
[user@bitcoin .bitcoin]$ sudo find /var/lib/bitcoin/Bitcoin-Qt.conf
find: '/var/lib/bitcoin/Bitcoin-Qt.conf': No such file or directory
[user@bitcoin .bitcoin]$ sudo find /etc/bitcoin/Bitcoin-Qt.conf
find: '/etc/bitcoin/Bitcoin-Qt.conf': No such file or directory

So apparently it's not in any of those locations... unless running find as root works as well as the other commands I've tried to use involving the system directories

Edit: found it...

As you maybe already noticed the syntax of find command was incorrect. Should be something like

find / -name Bitcoin-Qt.conf  -print

[Carlton Banks]

[user@bitcoin .bitcoin]$ find Bitcoin-Qt.conf
find: 'Bitcoin-Qt.conf': No such file or directory
[user@bitcoin .bitcoin]$ sudo find /var/lib/bitcoin/Bitcoin-Qt.conf
find: '/var/lib/bitcoin/Bitcoin-Qt.conf': No such file or directory
[user@bitcoin .bitcoin]$ sudo find /etc/bitcoin/Bitcoin-Qt.conf
find: '/etc/bitcoin/Bitcoin-Qt.conf': No such file or directory

So apparently it's not in any of those locations... unless running find as root works as well as the other commands I've tried to use involving the system directories

Edit: found it...

As you maybe already noticed the syntax of find command was incorrect. Should be something like

find / -name Bitcoin-Qt.conf  -print

You'll have to excuse my poor knowledge of the linux shell commands, I'm better than novice, but not much better

Edit: just tried since your rebuild, same error

You sure you ran

Code:

yum clean all

? The repos look fine now.

Yes, but I'll try again anyway, maybe you were still updating the repo when I did it the first time.

[Carlton Banks]

Working now. yum has found bitcoin.x86_64 0:0.9.2.1-1.fc20 again, and the Qt wallet is working as it was. Thanks error!

The situation with using bitcoind/bitcoin-server as a service is still difficult with Qubes. I believe what's happening is mirroring what happens also with bitcoin-qt when it's configured to use /var/lib/bitcoin as the datadir, namely that the blocks download but aren't/cannot be written to disk (if I quit and restart bitcoin-qt when it's reportedly dl-ing the blockchain to /var/lib/bitcoin, the block count starts from 0). If I run systemctl start bitcoin, Armory detects that bitcoind is running, but it doesn't see any new blocks, so it appears that bitcoind is behaving the same way bitcoin-qt does, despite having permission to access /var/lib/bitcoin. I'm thinking that this is because Qubes has SELinux set disabled by default (yum install bitcoin-server yields a page of permissions warnings).

It'd be incredibly cool to get bitcoind/bitcoin-server working as a service on Qubes-OS, using Armory would appear much less cluttered. However, I've figured out how to establish a Bitcoin-Qt desktop item that runs in Node mode (-disablewallet argument), so it's not so bad this way. Does Qubes need it's own dedicated package to install and configure bitcoind? I'm thinking that's possibly the case.

[error]

Working now. yum has found bitcoin.x86_64 0:0.9.2.1-1.fc20 again, and the Qt wallet is working as it was. Thanks error!

The situation with using bitcoind/bitcoin-server as a service is still difficult with Qubes. I believe what's happening is mirroring what happens also with bitcoin-qt when it's configured to use /var/lib/bitcoin as the datadir, namely that the blocks download but aren't/cannot be written to disk (if I quit and restart bitcoin-qt when it's reportedly dl-ing the blockchain to /var/lib/bitcoin, the block count starts from 0). If I run systemctl start bitcoin, Armory detects that bitcoind is running, but it doesn't see any new blocks, so it appears that bitcoind is behaving the same way bitcoin-qt does, despite having permission to access /var/lib/bitcoin. I'm thinking that this is because Qubes has SELinux set disabled by default (yum install bitcoin-server yields a page of permissions warnings).

It'd be incredibly cool to get bitcoind/bitcoin-server working as a service on Qubes-OS, using Armory would appear much less cluttered. However, I've figured out how to establish a Bitcoin-Qt desktop item that runs in Node mode (-disablewallet argument), so it's not so bad this way. Does Qubes need it's own dedicated package to install and configure bitcoind? I'm thinking that's possibly the case.

I'm not sure what the deal with Qubes OS is. When I get some time I'll play with it and see if I can figure out what's going on. I can't make any guarantees, though; it seems they have a completely different security model and who knows what it will need to run the bitcoin server successfully.

Right now, though, the more important thing is doing something about this horrible configuration file handling code. It's old, old code from Bitcoin that isn't at all object oriented and is very brittle. It got even more brittle with the 0.9 refactoring, which is where this latest issue came from. I _finally_ think I have a workaround, but I'm going to give it a few rounds of testing locally before I push it out. Eventually all this code really needs to be scrapped and rewritten.

[RedDiamond]

[user@bitcoin .bitcoin]$ find Bitcoin-Qt.conf
find: 'Bitcoin-Qt.conf': No such file or directory
[user@bitcoin .bitcoin]$ sudo find /var/lib/bitcoin/Bitcoin-Qt.conf
find: '/var/lib/bitcoin/Bitcoin-Qt.conf': No such file or directory
[user@bitcoin .bitcoin]$ sudo find /etc/bitcoin/Bitcoin-Qt.conf
find: '/etc/bitcoin/Bitcoin-Qt.conf': No such file or directory

So apparently it's not in any of those locations... unless running find as root works as well as the other commands I've tried to use involving the system directories

Edit: found it...

As you maybe already noticed the syntax of find command was incorrect. Should be something like

find / -name Bitcoin-Qt.conf  -print

My bad, it seems that actually you can use the find command as you tried. However it is a little bit unusual way to use the command (it works then like 'ls -R').

With Qubes I think the problem still is that some of file systems are mounted read only.

[Carlton Banks]

I'm not sure what the deal with Qubes OS is. When I get some time I'll play with it and see if I can figure out what's going on. I can't make any guarantees, though; it seems they have a completely different security model and who knows what it will need to run the bitcoin server successfully.

Qubes is interesting, it uses the Xen virtualisation software to created an OS built around compartmentalising everything, all using Fedora as the template distro. The GUI/desktop is bundled with with a set of presiding commands, libraries and scripts that provide an interface between the hypervisor and the layer for running VMs with actual applications. All the networking is run through dedicated network interface VM's, where the actual hardware adapter is assigned to that VM only at the hypervisor level (similarly possible with all the hardware devices, i.e. USB bus can be assigned to a single VM with no networking access at all). Further network proxy VM's can be run to enforce firewall rules, and are easy to configure. So, you can chain multiple network proxies together each with different network setting, e.g. WAN -> VPN -> Tor. It's a pretty smart concept.

It's still a bit immature, so there's the occasional upstream bug that can break some functionality, but it's come a long way since I first gave it a trial install. Playing with the most recent release has given me a pretty solid security environment for running Armory (Armory Offline runs in a VM without network, special secure hypervisor level copy-paste function lets you shuttle unsigned/signed transactions between online and offline domains).

Right now, though, the more important thing is doing something about this horrible configuration file handling code. It's old, old code from Bitcoin that isn't at all object oriented and is very brittle. It got even more brittle with the 0.9 refactoring, which is where this latest issue came from. I _finally_ think I have a workaround, but I'm going to give it a few rounds of testing locally before I push it out. Eventually all this code really needs to be scrapped and rewritten.

Sounds like a struggle. It is a little surprising to find such disharmony between the development projects and all the distros in the Linux world, although I'm beginning to understand just how many levels of interoperation there are (packaging format, desktop, architecture, repo & EOL distros/libraries all play their part, I'll hazard a guess that there are more...). Seems like the secret is to have as consumate a knowledge of Linux in all it's incarnations and permutations as possible, then it's possible to fix most things yourself  .

[error]

Sounds like a struggle. It is a little surprising to find such disharmony between the development projects and all the distros in the Linux world, although I'm beginning to understand just how many levels of interoperation there are (packaging format, desktop, architecture, repo & EOL distros/libraries all play their part, I'll hazard a guess that there are more...). Seems like the secret is to have as consumate a knowledge of Linux in all it's incarnations and permutations as possible, then it's possible to fix most things yourself  .

It's not that. The Bitcoin devs aren't hard to work with. The problem is Bitcoin wasn't originally designed with distro packaging in mind, and almost nobody (except possibly me) cares about it. I just want to see Bitcoin used more widely and more securely. Eventually getting Bitcoin into Fedora and Red Hat will help a LOT. And having used Linux for 20 years I have a little experience to draw on. Unfortunately I don't get paid for this and the donations have been pitifully small so far. Oh well. I'll keep at it.

[error]

Whoever just bought me a pizza, thanks

[error]

A security update for OpenSSL has been published which resolves several security issues, some of which may impact Bitcoin.

Please update your system as soon as possible, and then restart your Bitcoin client or server to ensure that you are running the updated code.

Updates are available now for EL and Fedora on x86_64 and i386. Fedora ARM builds will be made available within the next 24 hours.

[infertux]

Great work on the RPM packages error, it's nice to have proper SELinux support for Bitcoin.

I made a Chef cookbook which uses your packages - hope that's okay.

[error]

A security update for OpenSSL has been published which resolves four security issues, some of which may impact Bitcoin.

The updated OpenSSL version 1.0.1j is now available for EL and Fedora on x86_64, i386 and ARM (Fedora only) architectures.

Please update your system and then restart your Bitcoin client or server to ensure that you are running the updated code.

[error]

It appears that people in some parts of the United States are having trouble accessing the website and yum repositories.

The server is, of course, up and running fine. The trouble appears to be out on the network somewhere, and while I'm working to track it down, since the problem is not at my end there may be little that I can do.

Sometime in the next few days I'm going to set up rsync and open the repo up for mirroring. Donations toward - or of - a mirror would be appreciated.

---

Edit: Things seem to be fine now, but I'd appreciate reports from anyone who might still be having trouble reaching the repositories.

[error]

A security update for OpenSSL has been made available today which addresses several security vulnerabilities.

One of these (CVE-2014-3570) impacts 64-bit (x86_64) builds of Bitcoin, at least in theory. The remainder are low and moderate impact security issues, some of which may impact you depending on your configuration (e.g. if you use Bitcoin RPC with SSL/TLS).

Updates for the openssl packages in these repos are now available for x86_64 and i386. ARM builds will be posted in about four hours from now.

Remember to restart Bitcoin after installing the updates.

[marcus_of_augustus]

I stopped following the ridiculous charade that was the 'debate' for keeping ECC out of RH OpenSSL but have noticed that secp256k1 headers are there in the openssl-devel package and ECC functionality/support is generally in the openssl package now ...

do you have any update what the progress is on getting secp256k1 openssl support in the repos?

i.e. what's the latest farcical excuse?

anyway bitcoin has it's own secp256k1 library on git now so there are other options