Contribute to Open Source. Search issue labels to find the right project for you!

Raspbian on repo.powerdns.com - 1.1.x and master

PowerDNS/pdns
  • Program: dnsdist <!– delete the ones that do not apply –>
  • Issue type: Feature request

Short description

Please can a 1.1.x release be added to the raspbian section on repo.powerdns.com? currently only 1.0.x is available.

Master for raspbian has also not been updated since 2016.

Environment

  • Operating system: Raspbian GNU/Linux 8 (jessie)
  • Software version: 8 (jessie)
  • Software source: PowerDNS repository

Expected behaviour

  • 1.1.x section added
  • master package for raspbian kept up to date
Updated 19/06/2017 17:12

implement go-ds-badger

ipfs/go-ipfs

I’m very excited about the badger datastore, it seems to be very optimized for a lot of the same things that ipfs needs.

When i first looked into it, the interfaces had no error handling, but now they have fixed that problem. I would like to get a badger datastore backend written so we can start testing how ipfs performs with it.

Updated 17/06/2017 22:56

Error writing block to datastore: Access is denied.

ipfs/go-ipfs

Version information:

go-ipfs version: 0.4.9- Repo version: 5 System version: amd64/windows Golang version: go1.8.1

Type: Bug

<!– One of following: Critical - System crash, application panic. High - The main functionality of the application does not work, API breakage, repo format breakage, etc. Medium - A non-essential functionality does not work, performance issues, etc. Low - An optional functionality does not work. Very Low - Translation or documentation mistake. Something that really does not matter much but should be noticed for a future release. –>

Severity: Medium

Description:

Started ipfs daemon: ipfs daemon Runs for a bit and connects to peers. Starts throwing errors in the console. [0;37m16:48:35.891 [31mERROR [0;34m bitswap: [0mError writing block to datastore: Access is denied. [0;37mbitswap.go:322[0m and [0;37m16:48:39.904 [31mERROR [0;34mcommands/h: [0merr: write tcp4 127.0.0.1:5001->127.0.0.1:56762: wsasend: An established connection was aborted by the software in your host machine. [0;37mhandler.go:288[0m

Updated 12/06/2017 08:44

Repo is growing and growing

ipfs/go-ipfs

Version information:

go-ipfs version: 0.4.5-
Repo version: 5
System version: amd64/darwin
Golang version: go1.7.4

Type: Bug

Priority: P3

Description:

When creating a hashchain of objects (so each object links to a previous object), it seems repository gets much larger than expected. And it also just continues to grow and grow.

Reproduction: https://github.com/mitar/ipfs-create-chain

I started with empty repository (not sure why it is not completely empty, because I initialized it with -e):

$ date ; ./ipfs repo stat
Wed Mar 15 03:00:10 PDT 2017
NumObjects   5
RepoSize     334034
RepoPath     /Users/user/.ipfs
Version      fs-repo@5

After adding 10000 objects of a hashchain:

$ date ; ./ipfs repo stat
Wed Mar 15 03:01:16 PDT 2017
NumObjects   10005
RepoSize     2142370
RepoPath     /Users/user/.ipfs
Version      fs-repo@5

The last object in this hashchain is saying that the whole size is 1008672. 2142370 is more than twice as much.

After pinning the hashchain size jumps:

$ date ; ./ipfs repo stat
Wed Mar 15 03:01:24 PDT 2017
NumObjects   10267
RepoSize     5637553
RepoPath     /Users/user/.ipfs
Version      fs-repo@5

But leaving it running for 10 minutes just grows the repository:

$ date ; ./ipfs repo stat
Wed Mar 15 03:13:36 PDT 2017
NumObjects   10267
RepoSize     7167765
RepoPath     /Users/user/.ipfs
Version      fs-repo@5

After few more minutes:

$ date ; ./ipfs repo stat
Wed Mar 15 03:35:51 PDT 2017
NumObjects   10267
RepoSize     7452579
RepoPath     /Users/user/.ipfs
Version      fs-repo@5

And after few more hours:

$ date ; ./ipfs repo stat
Wed Mar 15 11:46:51 PDT 2017
NumObjects   10267
RepoSize     18612219
RepoPath     /Users/user/.ipfs
Version      fs-repo@5

What is happening here? This is a lot more than 1008672. OK, the list of all pins is probably around 1 MB more. So I would expect the repo to be around 2 MB.

There was no other use of the IPFS & daemon after the run of the initial script. I just left it running.

Updated 03/05/2017 04:10 19 Comments

More granular address announcements

ipfs/go-ipfs

Sometimes a go-ipfs listener can not directly bind to its external address. This is e.g. the case with NAT, where it binds to an IP address in the local network, while other nodes dial it using the local router’s public IP address. We jump through all kinds of hoops to work around that, and one of these is “observed addresses”, where other nodes tell us which addresses they’ve seen us using.

Another example are HTTP-based transports like /ws, which will in many cases be behind an SSL-terminating reverse proxy. Bound address: /ws, external address: /wss. There is a way to discover that we’re behind a reverse proxy (by passing a special HTTP header), but that would only work after the first request has come in. Until then, the node would be unaware of its /wss address.

We could just as well have an ExternalAddresses config option though (or ideally both). This might also be useful for announcing /dns addresses. The default bootstrappers will eventually be bootstrap.libp2p.io or so, and they’d be able to announce it.

Updated 31/05/2017 00:55 9 Comments

Broadwell - Problem adding packages.synocommunity.com repository to rs3617xs+

SynoCommunity/spksrc

Hello, it seems there is a problem adding packages.synocommunity.com repository to rs3617xs+ - it reports “Invalid location”. The same procedure on RS2211 works well.

Here are the http request and reply sniffed from the network … (packages.synocommunity.com was resolved to 104.31.94.179)

GET /?package_update_channel=beta&unique=synology_broadwell_rs3617xs%2B&build=8451&language=csy&major=6&arch=broadwell&minor=0&timezone=Amsterdam HTTP/1.1
Host: packages.synocommunity.com
User-Agent: synology_broadwell_rs3617xs+ DSM6.0-8451 Update 2 (package)
Accept: */*
HTTP/1.1 422 UNPROCESSABLE ENTITY
Date: Wed, 02 Nov 2016 11:47:48 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d1523eb3770083bbc6dad219f752ed3ab1478087268; expires=Thu, 02-Nov-17 11:47:48 GMT; path=/; domain=.synocommunity.com; HttpOnly
Server: cloudflare-nginx
CF-RAY: 2fb75a9440222348-FRA

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>422 Unprocessable Entity</title>
<h1>Unprocessable Entity</h1>
<p>The request was well-formed but was unable to be followed due to semantic errors.</p>

(and one more POST request using the same parameters)

Updated 10/05/2017 09:48 14 Comments

Fork me on GitHub