Upstream Package/Repo Mainainer

[indolering]

Thanks to PMC we now have packages for RedHat/Fedora/CentOS/SUSE and Debian/Ubuntu. PMC is willing to handle open it to OpenSUSE but has declined to do so for the other repos.

I know enough about package management to be dangerous, so I'm trying to do the next best thing and coordinate volunteers. This should be a fairly simple task as PMC is doing all of the backend work to make sure things are working.

Does anyone have familiarity with these projects?

Perhaps someone could get us started by maintaining a Launchpad PPA that syncs with PMC's repo? We should eventually get this all automated and figure out some functional tests. So, experience working with Jenkins or a desire to learn is a big plus!

There are are 3 related issues:

• I think the package should create the ~/.namecoin directory and namecoin.conf file by default. Here is what Jeremy_Rand and I worked out, note that the -hex 30 is to ensure ASCII characters and the 30 is much larger than a 20-digit a-zA-Z0-9 character password.

  Code: Select all

  mkdir ~/.namecoin && \
  echo "rpcuser=`whoami` \n\
  rpcpassword=`openssl rand -hex 30` \n\
  rpcport=8334" > ~/.namecoin/namecoin.conf
  

• We could distribute a pre-packaged copy of the blockchain, perhaps on Amazon's servers or via the Internet Archive (and hence a mutable torrents).
• The Debian FAQ on this lists some requirement about a removal script. I assume this would include removing all of ~/.namecoin but I don't see any such script.

Perhaps we should just include some sort of post-install script.

[domob]

I think this will be great - I've had exchanges with at least two people recently who are on GNU/Linux (one specifically a Debian derivative) and where I had to tell them that I'm not aware of binaries. Building from source is not exactly complicated if you have done it before, but at least getting all the right dependencies plus working with the command-line is also not trivial.

Regarding your script:

• Maybe add "-p" to the mkdir command, so that it doesn't fail in case .namecoin exists already? Also, I think Debian's aptitude (and also apt-get, I presume) provides a way to both "uninstall" a package without removing configuration files, and to "purge" it, removing everything. Have you thought about what those would do to the configuration directory? That said, I've never done a Debian package myself, so I only know these user-side things.
• Isn't the default rpcport 8336?
• I don't think we should distribute the blockchain for trust reasons. Also the Debian package of Bitcoin didn't do it back in the day (I've last used it two years ago), and I think that users installing Namecoin-Qt should be fine with a blockchain download. Otherwise, they should use a lite client in the future. (Alternatively, I think one could ask the user with an installation hook script whether they want to download a GPG-verified copy of the blockchain from some server; but don't do it without their explicit consent.)

[pmc]

This should be a fairly simple task as PMC is doing all of the backend work to make sure things are working.

Well, not "all". The debian/ubuntu stuff on OBS creates debian/ubuntu packages from what is not a proper debian/ubuntu source package. The difference is mostly how patches and additional source files are handled, the rest should be OK.

• I think the package should create the ~/.namecoin directory and namecoin.conf file by default. Here is what Jeremy_Rand and I worked out, note that the -hex 30 is to ensure ASCII characters and the 30 is much larger than a 20-digit a-zA-Z0-9 character password.

  Code: Select all

  mkdir ~/.namecoin && \
  echo "rpcuser=`whoami` \n\
  rpcpassword=`openssl rand -hex 30` \n\
  rpcport=8334" > ~/.namecoin/namecoin.conf
  

IMO the proper way to do that is to use a wrapper script around namecoin / namecoind. That's not something that should happen during package installation.

• The Debian FAQ on this lists some requirement about a removal script. I assume this would include removing all of ~/.namecoin but I don't see any such script.

I don't think that requirement applies here. Users certainly don't want to have their ~/.namecoin/wallet.dat removed.

[indolering]

I think this will be great - I've had exchanges with at least two people recently who are on GNU/Linux (one specifically a Debian derivative) and where I had to tell them that I'm not aware of binaries. Building from source is not exactly complicated if you have done it before, but at least getting all the right dependencies plus working with the command-line is also not trivial.

The install instructions on the wiki have also been fairly broken for months. It's better now, but it's not where it should be.

Regarding your script:

• Maybe add "-p" to the mkdir command, so that it doesn't fail in case .namecoin exists already? Also, I think Debian's aptitude (and also apt-get, I presume) provides a way to both "uninstall" a package without removing configuration files, and to "purge" it, removing everything. Have you thought about what those would do to the configuration directory? That said, I've never done a Debian package myself, so I only know these user-side things.

Great!

[*] Isn't the default rpcport 8336?

That is what it was on the wiki for a while but there was conflicting instructions, sugarpuff found 8336 in the namecoin codebase so I changed it. Maybe that was a mistake.

... (Alternatively, I think one could ask the user with an installation hook script whether they want to download a GPG-verified copy of the blockchain from some server; but don't do it without their explicit consent.)[/list]

Yes, this is what I was thinking.

This should be a fairly simple task as PMC is doing all of the backend work to make sure things are working.

Well, not "all". The debian/ubuntu stuff on OBS creates debian/ubuntu packages from what is not a proper debian/ubuntu source package. The difference is mostly how patches and additional source files are handled, the rest should be OK.

Shh!!! Don't tell them it might be more work!

• I think the package should create the ~/.namecoin directory and namecoin.conf file by default. Here is what Jeremy_Rand and I worked out, note that the -hex 30 is to ensure ASCII characters and the 30 is much larger than a 20-digit a-zA-Z0-9 character password.

  Code: Select all

  mkdir ~/.namecoin && \
  echo "rpcuser=`whoami` \n\
  rpcpassword=`openssl rand -hex 30` \n\
  rpcport=8334" > ~/.namecoin/namecoin.conf
  

IMO the proper way to do that is to use a wrapper script around namecoin / namecoind. That's not something that should happen during package installation.

That sounds like the sanest option to me, I just don't know enough C to submit a pull request for it. Maybe I should just make an issue ticket.

• The Debian FAQ on this lists some requirement about a removal script. I assume this would include removing all of ~/.namecoin but I don't see any such script.

I don't think that requirement applies here. Users certainly don't want to have their ~/.namecoin/wallet.dat removed.

The blockchain and other database files do take up over a gig of space, however. But I am ALL for not having to do any more work.

[khal]

Isn't the default rpcport 8336?

Yes, rpcpport = 8336 (and daemon port = 8334)

IMO the proper way to do that is to use a wrapper script around namecoin / namecoind. That's not something that should happen during package installation.

That sounds like the sanest option to me, I just don't know enough C to submit a pull request for it. Maybe I should just make an issue ticket.

The namecoin client knows where to write the file for each OS/user and already checks if the file exists, so it seems logical to include it there.
I vote for the issue too :p

I don't think that requirement applies here. Users certainly don't want to have their ~/.namecoin/wallet.dat removed.

I confirm, user profiles are not concerned by this, only this shared between several users (ex: the btcd daemon [a bitcoin implementation in go] has a shared blockchain usable by several users).

So, experience working with Jenkins or a desire to learn is a big plus!

I use jenkins everyday at work (with php projects), I created new projects, ant files, etc. So, I can help any people who want learn how it works.
Jenkins allows to automate things, on each commit or manually, for ex : it could launch syntax checking, unit tests, compilation, file upload, etc.Source package creation can be one of its tasks.

For now, we should put the link to the download page on the websites and improve the build scripts.

When we'll have both way to install namecoin (from our distribs & from opensuze builds), I suggest we keep both for people that want to use the latest version (versions included in distributions can be late & no update is possible, ex: debian).

[indolering]

Isn't the default rpcport 8336?

Yes, rpcpport = 8336 (and daemon port = 8334)

Whoops! *runs around and reverts changes*

FWIW even MediaWiki's install article was out of date not long ago :p

I don't think that requirement applies here. Users certainly don't want to have their ~/.namecoin/wallet.dat removed.

I confirm, user profiles are not concerned by this, only this shared between several users (ex: the btcd daemon [a bitcoin implementation in go] has a shared blockchain usable by several users).

A shared blockchain makes a hell of a lot more sense than having a separate on in each user directory. I think we should move to this setup by default.

So, experience working with Jenkins or a desire to learn is a big plus!

I use jenkins everyday at work (with php projects), I created new projects, ant files, etc. So, I can help any people who want learn how it works.
Jenkins allows to automate things, on each commit or manually, for ex : it could launch syntax checking, unit tests, compilation, file upload, etc.Source package creation can be one of its tasks.

Yes, the OpenSUSE Build Service installs but it doesn't do any functional testing so we will eventually need to perform those things locally. But manual submissions are fine for now.

For now, we should put the link to the download page on the websites and improve the build scripts.

When we'll have both way to install namecoin (from our distribs & from opensuze builds), I suggest we keep both for people that want to use the latest version (versions included in distributions can be late & no update is possible, ex: debian).

I've already got the link up on the wiki and I'm filing a ticket now.

[domob]

I confirm, user profiles are not concerned by this, only this shared between several users (ex: the btcd daemon [a bitcoin implementation in go] has a shared blockchain usable by several users).

A shared blockchain makes a hell of a lot more sense than having a separate on in each user directory. I think we should move to this setup by default.

Yes, I also believe a shared blockchain will be nice. However, note that in that case you have to be careful with who has write access to the blockchain (and consequently is running the daemon updating the chain) so that a malicious user cannot manipulate data for everyone else on the system. Also, locking will probably be a concern if multiple users run daemons accessing the blockchain (but at least only one process is writing to it at each time).

[khal]

Yes, I also believe a shared blockchain will be nice. However, note that in that case you have to be careful with who has write access to the blockchain (and consequently is running the daemon updating the chain) so that a malicious user cannot manipulate data for everyone else on the system. Also, locking will probably be a concern if multiple users run daemons accessing the blockchain (but at least only one process is writing to it at each time).

While namecoind manages the wallet, we shouldn't share its access. So, we have some time to see this happen :p

[domob]

Yes, I also believe a shared blockchain will be nice. However, note that in that case you have to be careful with who has write access to the blockchain (and consequently is running the daemon updating the chain) so that a malicious user cannot manipulate data for everyone else on the system. Also, locking will probably be a concern if multiple users run daemons accessing the blockchain (but at least only one process is writing to it at each time).

While namecoind manages the wallet, we shouldn't share its access. So, we have some time to see this happen :p

In case my explanation was not clear, I imagine that multiple namecoind instances would run, managing the individual wallets for each user. All of them would access the same blockchain, though, which would be in a system-wide shared location. One particular namecoind instance running by some kind of "admin" user would be the one updating the blockchain, while all others (as well as the ordinary users on a file-system level) would only have read access to it.

[dolphin]

We build and support NameCoin on RedHat and CentOS for our own needs (http://www.securedolphin.com). We also blogged on changes, necessary to compile and run NameCoin on CentOS and RedHat (http://securedolphin.com/blog/running-n ... -redhat-62 and http://securedolphin.com/blog/building- ... -centos-62). We'd be happy to take on the RedHat/CentOS package maintenance as expression of our gratitude to the NameCoin community.

BTW, it seems that CentOS/RedHat builds are failing to produce RPM due to dependency package naming problem (the BerkleyeDB is called differently on CentOS/RedHat). I imagine there are a few more problems that would need to be resolved before the build yields an RPM.