Bitcoin Forum
April 24, 2019, 09:22:52 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 4 5 »  All
  Print  
Author Topic: Bitcoin RPM packages for Fedora and Red Hat Enterprise Linux  (Read 31234 times)
error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
August 23, 2012, 05:01:06 AM
Last edit: January 08, 2015, 10:05:42 PM by error
 #1



Now available: Bitcoin for Fedora and Red Hat Enterprise Linux

Quick Start:

  • Install the bitcoin-release RPM for RHEL or Fedora.
  • Install the bitcoin package for the Bitcoin GUI, or the bitcoin-server package for bitcoind, using yum install <packagename>.
  • If using bitcoind, start it with run_init service bitcoin start as root (on Fedora, use systemctl start bitcoin.service instead), and chkconfig bitcoin on (on Fedora, use systemctl enable bitcoin.service) to enable automatic startup.
  • If using bitcoin GUI, click the icon in your applications menu. You should find it filed under Office.

Info:

I am pleased to present Bitcoin RPM repositories for Fedora and Red Hat Enterprise Linux.

These repositories provide OpenSSL with EC support, resolving the primary issue holding back Bitcoin builds for Fedora and RHEL. They also provide an SELinux-enhanced bitcoin daemon, protecting the server's Bitcoin wallet against unexpected exploits of other system services. The whole stack has undergone nearly two months of testing prior to today's announcement to ensure system compatibility and security.

More information and a FAQ can be found at the repository homepage.

Of particular note, bitcoind as distributed here has some important differences from that distributed by the project. The primary differences are SELinux support and having bitcoind store all its files in standard locations such as /etc/bitcoin and /var/lib/bitcoin. It is otherwise unmodified.

Known Issues:

  • The system tray icon is blank when running bitcoin-qt under GNOME. (It appears normally under KDE.) This seems to be an upstream issue.

Donate:

If you approve of this project and wish it to continue, send donations to 17fDs8d2ACKhfwGHMADpWtBGiU6WneyxkZ , click on the image above with a bitcoin URL-enabled client, or scan its QR code. If this helps you build a more secure Bitcoin service, send a big donation. Grin

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
1556140972
Hero Member
*
Offline Offline

Posts: 1556140972

View Profile Personal Message (Offline)

Ignore
1556140972
Reply with quote  #2

1556140972
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1556140972
Hero Member
*
Offline Offline

Posts: 1556140972

View Profile Personal Message (Offline)

Ignore
1556140972
Reply with quote  #2

1556140972
Report to moderator
1556140972
Hero Member
*
Offline Offline

Posts: 1556140972

View Profile Personal Message (Offline)

Ignore
1556140972
Reply with quote  #2

1556140972
Report to moderator
1556140972
Hero Member
*
Offline Offline

Posts: 1556140972

View Profile Personal Message (Offline)

Ignore
1556140972
Reply with quote  #2

1556140972
Report to moderator
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2870
Merit: 1129



View Profile
August 23, 2012, 10:08:51 PM
 #2

Can you confirm that installing your RPM will remove the system libraries for OpenSSL (libssl and libcrypto) and install your own versions in its place?


error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
August 23, 2012, 10:20:39 PM
Last edit: December 18, 2012, 07:25:44 AM by error
 #3

Can you confirm that installing your RPM will remove the system libraries for OpenSSL (libssl and libcrypto) and install your own versions in its place?

It did on all of my test boxes. I spent almost a full day on making sure this worked. Smiley

This Bitcoin repository ships separate OpenSSL packages which do not replace the system packages and are reserved for the exclusive use of the Bitcoin daemon and Qt GUI.

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2870
Merit: 1129



View Profile
August 23, 2012, 11:19:46 PM
 #4

Can you confirm that installing your RPM will remove the system libraries for OpenSSL (libssl and libcrypto) and install your own versions in its place?

It did on all of my test boxes. I spent almost a full day on making sure this worked. Smiley

Ok thanks for confirming that ... different people with different trust levels will view this fact differently but probably a big, fat red warning is in order to make it clear to users that this is what will happen.

E.g. if you have ever tried to remove OpenSSL from your system (I do not recommend you do this btw!) you will notice how many security critical programs require these libraries as a dependency ... putting a binary libssl and libcrypto from a dev. other than official repo will be a big leap of trust for an enterprise server system administrator, just for example.

error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
August 23, 2012, 11:29:05 PM
Last edit: December 18, 2012, 07:26:40 AM by error
 #5

Yeah, don't ever remove OpenSSL or you'll break your system beyond repair.

I spent a very long time testing everything I could to ensure the replacement libraries would work 100% with other existing programs on the system. (Which is partly why they're the 1.0.0 branch and not 1.0.1.) So far so good.

As for trust, that's why there are source RPMs. If you unpack it and look around you will find an OpenSSL source tarball which is completely pristine (unlike Red Hat's which has been heavily stripped). I would have liked to avoid having to ship OpenSSL, but there was no good way to do so. Fortunately it looks like Red Hat might finally fix this problem soon (it's tied up in their legal department right now). Once they do, I will be happy to not have to ship OpenSSL.

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
August 25, 2012, 05:35:02 AM
 #6

Now that this has been out a couple of days with zero issues reported, (and I haven't lost all my bitcoins either! I run this code myself) I'd like to ask your comment on:

What other Bitcoin-related software needs to be made available for Red Hat/Fedora?

Right now I am considering Electrum, MultiBit and Armory clients. I don't normally use any of these, so there will be a short delay in getting any of them packaged.

In addition to alternative clients, what else should be packaged for distribution?

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
August 25, 2012, 04:29:05 PM
 #7

Now that this has been out a couple of days with zero issues reported,
Only yourself and desperadoes would try your RPMs. May I suggest that:

1) don't replace any RedHat libraries, everything private should
be linked with "-rpath" to a private directory or "$ORIGIN"
2) don't run bitcoind as root, but as a regular user (despite all your SELinux configuration)

or:

3) get yourselves hired at RedHat

Good luck.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
August 25, 2012, 07:39:55 PM
 #8

Since you didn't even bother to look, you are probably unaware that I do not run bitcoind as root.

Not replacing a system library is a good idea; it just turns out to be much harder than you think it is.

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
August 25, 2012, 08:39:23 PM
 #9

Since you didn't even bother to look, you are probably unaware that I do not run bitcoind as root.
I apologise, I was wrong. Indeed the /etc/rc.d/init.d/bitcoin starts the app as user "bitcoin". I couldn't find any "useradd" and "groupadd" calls, but they are there in the RPMs. As it turns out my rpm2cpio tool is buggy and doesn't do the proper conversion for some RPMs. It appears that the packaged files are owned by "root", but it may be another bug in my tool. As you may have expected I wouldn't dare to actually install the RPM.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
August 25, 2012, 09:06:57 PM
 #10

I apologise, I was wrong. Indeed the /etc/rc.d/init.d/bitcoin starts the app as user "bitcoin". I couldn't find any "useradd" and "groupadd" calls, but they are there in the RPMs. As it turns out my rpm2cpio tool is buggy and doesn't do the proper conversion for some RPMs. It appears that the packaged files are owned by "root", but it may be another bug in my tool. As you may have expected I wouldn't dare to actually install the RPM.

The packaged files are supposed to be owned by root. That's bog standard security. The binaries should not have access to modify themselves.

There's a fine line between distrust and paranoia. It's very easy to verify that the RPMs are good. That's why we have source RPMs in the first place. A distrustful person would inspect the source RPMs carefully to ensure there was no funny business going on, and perhaps rebuild them himself if they appeared OK.

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
August 25, 2012, 09:33:09 PM
 #11

The packaged files are supposed to be owned by root. That's bog standard security. The binaries should not have access to modify themselves.
I'm sorry, I was expecting "bin:bin" not "root:root" as the owner of the read-only files.

There's a fine line between distrust and paranoia. It's very easy to verify that the RPMs are good. That's why we have source RPMs in the first place. A distrustful person would inspect the source RPMs carefully to ensure there was no funny business going on, and perhaps rebuild them himself if they appeared OK.
The main motivation is neither distrust nor paranoia. The main problem with the RedHat package manager is the difficulty of recovering from the situation where a RHN system update kills customer's own applications. The secondary problem is that by replacing an RH-provided library you implicitly break the RedHat's service contract agreement; i.e. RedHat gets off the hook on the support of such a system.

The ternary problem (but for me primary problem) is basically a replay of the "Windows DLL hell" game under another operating system. I'm not going to play it and would not recommend anyone to play it unless they get paid by the hour for refixing the same problems. Side-by-side is the way to go and Linux supports it fairly well (using -rpath and $ORIGIN).

I say all this as a long-time RedHat Partner.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
August 25, 2012, 09:44:52 PM
 #12

I'm sorry, I was expecting "bin:bin" not "root:root" as the owner of the read-only files.

The result is much the same either way.

The main motivation is neither distrust nor paranoia. The main problem with the RedHat package manager is the difficulty of recovering from the situation where a RHN system update kills customer's own applications. The secondary problem is that by replacing an RH-provided library you implicitly break the RedHat's service contract agreement; i.e. RedHat gets off the hook on the support of such a system.

This is a valid concern for people running RHEL. A bit less so for those running CentOS or another clone, since they aren't getting support anyway.

The ternary problem (but for me primary problem) is basically a replay of the "Windows DLL hell" game under another operating system. I'm not going to play it and would not recommend anyone to play it unless they get paid by the hour for refixing the same problems. Side-by-side is the way to go and Linux supports it fairly well (using -rpath and $ORIGIN).

This is a reasonable concern. I hate DLL hell myself, and I'm perfectly willing to give this another go. I actually tried this at first, and RPM did not want to cooperate. So I'll beat on it some more.

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
August 25, 2012, 10:42:56 PM
 #13

This is a reasonable concern. I hate DLL hell myself, and I'm perfectly willing to give this another go. I actually tried this at first, and RPM did not want to cooperate. So I'll beat on it some more.
Thank you for your understanding. I know my position on software updates isn't the most common, but it did and it does hold the value pretty well.

May I suggest that you also "privatize" boost:: ? My reasoning is the same and I know that the potential market (for consulting, support, etc.) would greatly increase. I'm not on the market myself, but I see people needlessly shutting themselves out and find that regretfull. This really depends on the default GNU compiler for particular RHEL, not on the boost:: itself. But if you already have a test installations then the additional work required is fairly small.

Admittendly I'm somewhat extreme in software conservatism having supported RHEL2.1 until the beginning of this year. The money was good, and the savings for my clients (from e.g. not upgrading ColdFusion from Macromedia to Adobe) were staggering.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
August 26, 2012, 01:43:21 AM
 #14

May I suggest that you also "privatize" boost:: ? My reasoning is the same and I know that the potential market (for consulting, support, etc.) would greatly increase. I'm not on the market myself, but I see people needlessly shutting themselves out and find that regretfull. This really depends on the default GNU compiler for particular RHEL, not on the boost:: itself. But if you already have a test installations then the additional work required is fairly small.

Don't use the system provided Boost library?! There's nothing wrong with it, as far as I know. Or did you mean something else?

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
August 26, 2012, 02:07:22 AM
Last edit: August 26, 2012, 02:33:01 AM by 2112
 #15

Don't use the system provided Boost library?! There's nothing wrong with it, as far as I know. Or did you mean something else?
I took the following quote at the face value, maybe incorrectly.
Quote from: error
Q. Do you support Red Hat Enterprise Linux 5?

A. I have no plans to support Red Hat Enterprise Linux 5 at this time. Certain libraries (such as Boost) included with RHEL5 are too old to support current versions of Bitcoin and cannot be safely updated without risking breakage to other parts of the existing system.
I'm familiar with the "upgrade treadmill" as a way of revenue pumping and padding the billable hours, but my position is that the only way to win is to not play. I'm positive that RedHat will change the key libraries from underneath of your program, so prepare early. Ubuntu does that all the time, but the core developers are happy to play.

Edit: I'm not proposing that you support GNU C++ 2.96 and RH7.2/RHEL2.1; but I see that RedHat still actively supports it in RHEL6. Apparently they have enough customers/partners who refused to jump on the treadmill:

compat-libstdc++-296-2.96-144.el6.i686.rpm

2010-05-17 - Jakub Jelinek  <...> 2.96-144
- ensure libstdc++.so is linked with -Wl,-z,noexecstack (#592519)
2010-04-26 - Dennis Gregorovic <...> - 2.96-143.2
- Rebuilt for RHEL 6
Related: rhbz#566527

The above is just one of the things I had memorized from many years ago. I actually never installed that release except in virtual machines. But I see that the general strategy is still working for many of the RedHat's customers/partners.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
August 26, 2012, 03:01:10 AM
 #16

Ah, OK, so that is what you meant. Sure it would make it easy to build it on EL5. Probably be a couple of days before I can get around to that part, though.

Though I don't really expect somebody to be dumb enough to use an ancient OS for a new project, I suppose it could happen...

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
August 26, 2012, 03:13:32 AM
 #17

Though I don't really expect somebody to be dumb enough to use an ancient OS for a new project, I suppose it could happen...
I can assure you that RHEL5.* is widely used, probably still even more than RHEL6.* . Think of all the people who already have things/projects going on for them and making money (or at least sleeping peacefully at night). They were maybe thinking of adding Bitcoin to them as a trial. The stridency of the core developers with respect to supporting only the most recent Ubuntu was really off-putting for them.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
August 26, 2012, 05:01:46 AM
 #18

Though I don't really expect somebody to be dumb enough to use an ancient OS for a new project, I suppose it could happen...
I can assure you that RHEL5.* is widely used, probably still even more than RHEL6.* . Think of all the people who already have things/projects going on for them and making money (or at least sleeping peacefully at night). They were maybe thinking of adding Bitcoin to them as a trial. The stridency of the core developers with respect to supporting only the most recent Ubuntu was really off-putting for them.

EL5 hasn't reached end of life yet. I was thinking of EL4 and prior, old versions of Fedora, and maybe Windows 2000 Datacenter, all of which I've seen in active use recently.

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
Daily Anarchist
Hero Member
*****
Offline Offline

Activity: 615
Merit: 500



View Profile WWW
October 15, 2012, 05:59:19 AM
 #19

The Bitcoin-release-1.4 is an older version of Bitcoin, right? It's not 0.7.0?

So, there's no way to get 0.7.0 on my Fedora 17?

Discover anarcho-capitalism today!
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2870
Merit: 1129



View Profile
October 15, 2012, 11:45:24 PM
 #20

The Bitcoin-release-1.4 is an older version of Bitcoin, right? It's not 0.7.0?

So, there's no way to get 0.7.0 on my Fedora 17?

You can run with the multiply signed binaries the dev team publishes.
Or you can build (or otherwise install somehow) a local version of openssl with ecdsa support and build bitcoin 0.7.0 locally upon that.

Pages: [1] 2 3 4 5 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!