pacserve - easily share Pacman packages between computers

Xyne · 2013-06-30 18:29:10

Have you tested the "--peer" option?

You can run pacserve directly in a terminal (after stopping the service) with

pacserve --peer http://...:15678/

where "..." should be replaced with the IP address of the other server, obviously.

If that works and you have a managed switch or router, make sure that it is configured to forward UDP/multicast packets.
If the peer option doesn't work then I'm out of ideas.

Myshkin · 2013-06-30 20:44:41

Ok, it seems to be working with --peer but that's going to be tedious if we continue to grow. We have to pay extra if we go over our monthly bandwidth limit and we're a non-profit on a very limited budget. I'm needing to add 3 computers to the network, all of which need Arch installed and kept regularly updated, which is what prompted me to find a way to save bandwidth.

I'm using a managed router but only as a switch. The multicast option is checked and firewall turned off. Firewall is on the gateway computer.

Seems like the problem must be with multicast but it looks more complicated than I can justify spending time trying to figure it out. I'll live with --peer for now. Thanks for your help. I'm going to leave this open a couple of days to see if anyone has any suggestions.

Xyne · 2013-06-30 22:12:26

I would check that each computer's firewall allows outgoing multicast packets. The pacserve-ports service only configures the inbound firewall.

You could also try connecting two computers together directly by cable if you know how to set up basic networking. You could then confirm that the problem is the router.

I'm going to ask fukawi2 to take a look at this thread as he is one of the community networking gurus. He may have some ideas. In the meantime, it may help if you post the some information about your router and how you manage the local firewalls.

fukawi2 · 2013-06-30 22:53:41

What are the IP Addresses of the 2 hosts?

Can you post the output of this command on the client?

tcpdump -lnn -i eth0 host 224.3.45.67 or port 15678

Myshkin · 2013-07-01 04:42:58

@Xyne
I have a crossover cable and will give that a try if needed but I think we've found something below.
As for firewall, well, er, ahem, perhaps that was something Debian did for me and like a lot of other things, I need to learn about it since switching to Arch. I pretty much blindly follow whatever the HOWTOs or Wikis say. I'm pretty lax about it. Maybe I've just been lucky but have never had any problems with net vandals.

Hmm, in a previous post, I said I turned off all firewalls, but I should have said "turned off all _known_ firewalls."

@fukawi2
Machine 192.168.1.11:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s2, link-type EN10MB (Ethernet), capture size 65535 bytes
06:29:30.713728 IP 192.168.1.11 > 224.3.45.67: igmp v2 report 224.3.45.67
06:31:30.327044 IP 192.168.1.11 > 224.3.45.67: igmp v2 report 224.3.45.67
06:32:15.256335 IP 192.168.1.11.41371 > 224.3.45.67.15679: UDP, length 59
...

Machine 192.168.1.102

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), capture size 65535 bytes

Perhaps 102 has a problem?
102 has the shared modem. In following the wiki to set up the shared modem, I think I remember doing some firewall stuff.

Last edited by Myshkin (2013-07-01 04:44:05)

fukawi2 · 2013-07-01 05:04:35

OK, I'm assuming 1.11 is the server, and 1.102 is the client. Clearly the traffic is leaving the server, but it's never getting to the client (firewall is irrelevant here; tcpdump shows what's "on the wire" before netfilter does anything).

How are the 2 machines connected? Directly to the same switch? Is it a managed switch? Something else in between there? I suspect using your cross-over cable will work, and there's something in between there that isn't handling the multicast traffic properly....

Myshkin · 2013-07-01 06:11:45

FWIW, I connected the 2 computers using a crossover cable. Quickserve still worked but no change for pacserve. AFAIK, I've done nothing to prevent multicast packets. Is there something I need to do to specifically allow them?

Myshkin · 2013-07-01 06:28:07

Sorry, I began my previous reply before seeing your post. I work with constant interruptions and I'm not used to anyone being online at this time so didn't think to preview it. I didn't think to try the tcpdump with the crossover. With the crossover, I'm getting this now on 1.102:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:13:37.554417 IP 192.168.1.11.49216 > 224.3.45.67.15679: UDP, length 59
09:18:37.651361 IP 192.168.1.11.41347 > 224.3.45.67.15679: UDP, length 59

1.11 remains the same. Both machines are running pacserve, so shouldn't we also be seeing packets from 1.102?

Still, neither computer adds the other in pacserve.

fukawi2 · 2013-07-01 07:26:36

Myshkin wrote:

Both machines are running pacserve, so shouldn't we also be seeing packets from 1.102?

@Xyne; is that correct? Both hosts should be multicasting?

Are you sure enp0s1 is the correct interface?
Can you tcpdump the below on each host, and ping each way to see that the dump is correct?

tcpdump -lnn -i eth0 icmp

Replace eth0 as appropriate of course.

Myshkin · 2013-07-01 08:37:47

Guys, thanks so much for your help. I think we've about got it.

tcpdump: eth0: No such device exists

"tcpdump -lnn -i enp1s0 icmp" looks normal on both computers--requests and replies.

I replaced the router with a simple switch since no one is using wifi at the moment and added a third computer (1.15) that I just finished installing Arch on.
tcpdump output for 1.102 is now:

listening on enp1s0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:48:38.233117 IP 192.168.1.11.58858 > 224.3.45.67.15679: UDP, length 59
...
10:33:39.050079 IP 192.168.1.11.40480 > 224.3.45.67.15679: UDP, length 59
10:33:55.545661 IP 192.168.1.15.51068 > 224.3.45.67.15679: UDP, length 59

1.11 tcpdump looks like the above as well except a lot more follows of communication back and forth between 1.11 and 1.15.
1.11 and 1.15 immediately added each other with pacserve.

So, the router is probably one problem and I can deal with it later.
1.102 is still a problem. Unfortunately, it is my computer and the one I use to test packages with, so I really need it in the loop if possible.

FWIW, this project largely started because I wanted to change 1.102 to use netctl but got a bit nervous at the warning that if not done properly the network might not work. 1.11 was running Ubuntu and I couldn't get the mobile modem to work on it, so if the change didn't work, I could be left with no Internet. I decided to convert 1.11 to Arch and thus should be able to move the modem to 1.11 and update 1.102 to using netctl if that would make things easier.

fukawi2 · 2013-07-01 08:49:51

I'm confused; summarize the 3 computers now?
1.11 ==> Good computer?
1.102 ==> Your computer, not working.
1.15 ==> New computer, working fine with 1.11

So the problem is definitely with 1.102?

You've plugged 1.102 into the same switch port as 1.15 and it still doesn't work?

Myshkin · 2013-07-01 09:35:28

That's correct. pacserve on 1.102 (chanan002) is doing this:

Jul 01 11:28:41 chanan002 pacserve[5588]: [2013-07-01 11:28:41 EAT] INFO: announcing presence via multicast (group: 224.3.45.67)
Jul 01 11:33:42 chanan002 pacserve[5588]: [2013-07-01 11:33:42 EAT] INFO: announcing presence via multicast (group: 224.3.45.67)

pacserve on 1.11 and 1.15 are doing the same thing but they have their own names in the place of chanan002. But tcpdump on 1.102 is only seeing this:

11:28:56.524417 IP 192.168.1.15.34525 > 224.3.45.67.15679: UDP, length 59
11:33:40.198540 IP 192.168.1.11.53034 > 224.3.45.67.15679: UDP, length 59
11:33:56.620811 IP 192.168.1.15.43232 > 224.3.45.67.15679: UDP, length 59

which is exactly the same thing 1.11 and 1.15 are seeing.

Thus, it seems to me that 1.102 is unable to send multicast for some reason. ...
AHHHH! I've got it. Pacserve on 1.102 is multicasting via the ppp0 interface to the world rather than to the local network. I feared it would be something simple and stupid on my part.

Myshkin · 2013-07-01 09:53:47

I've tried both the --address and --multicast-address options to use 192.168.1.102 but they don't seem to change anything. Suggestions?

fukawi2 · 2013-07-01 09:58:57

Myshkin wrote:

AHHHH! I've got it. Pacserve on 1.102 is multicasting via the ppp0 interface to the world rather than to the local network. I feared it would be something simple and stupid on my part.

That won't be helping

So it is all working now? Or is 102 still isolated?

Myshkin · 2013-07-01 12:46:42

@fukawi2
Thanks so much! I've got it working.

@Xyne
Thanks. Alas, I'm not exactly sure why it started working. I tried a number of things but I *think* it was "ip route add 224.0.0.0/4 dev enp1s0" which is supposed to tell the kernel which interface multicasting should use if I understand it. Perhaps a better solution would be yet another program option for the interface to use and add a specific sock.bind statement in the multicast functions rather than relying on the kernel default.

Xyne · 2013-07-01 19:29:05

@Myshkin
I have added a new option: --multicast-interface
When used, multicast packets should be sent to the specified interface. It may be passed multiple times to specify multiple interfaces. The default should be to use all interfaces.

As I was making that change I also updated the --address and --multicast-address options to accept interface names. I am just going to run a few more tests here before I upload it. It should be up within the next hour. Note that the changes are in the python3-threaded_servers backend package, so watch that for updates.

edit: uploaded

Last edited by Xyne (2013-07-01 19:49:22)

Myshkin · 2013-07-02 12:12:43

Thanks much, Xyne. Now, if I could just find something similar for AUR.

Xyne · 2013-07-02 19:18:03

Myshkin wrote:

Thanks much, Xyne. Now, if I could just find something similar for AUR.

Build the packages on one system and host them in a local repo. repo-add is easy to use. If you want to sign it then you may find repo-add_and_sign useful.

Once you have the local repo, server it to the other systems via any http server. You could even use quickserve for that.

fukawi2 · 2013-07-02 22:57:41

http://aurbin.net
</shameless plug>

Xyne · 2013-07-03 00:10:44

fukawi2 wrote:

http://aurbin.net
</shameless plug>

Feel free to shamelessly plug it by submitting metadata for repoman.

Myshkin · 2013-07-03 07:40:17

Had to reconfigure my network and had the same old problem. Tried the new --multicast-interface and it works perfectly! Well done!

Xyne · 2013-07-03 21:08:04

Great! Thanks for the feedback!

darnir · 2013-09-18 14:02:48

I just tried installing and using pacserve. I installed pacserve from Xyne's x86_64 repo and started the relevant systemd services.

I do not use iptables, so I didn't need to plug that service.

Once that was done I tried running:

# pacsrv -Syu

This gives me the following output:

error: could not rename /var/lib/pacman/sync/testing.db.part to /var/lib/pacman/sync/testing.db (No such file or directory)
Initializing download: http://localhost:15678/pkg/?repo=testing
Opening output file /var/lib/pacman/sync/testing.db.part
Server unsupported, starting from scratch with one connection.
Starting download

Connection 0 finished                                                          ]

Downloaded 699.3 kilobytes in 0 seconds. (1130.93 KB/s)
Initializing download: http://archlinux.limun.org/testing/os/x86_64/testing.db
File size: 24249 bytes
No state file, cannot resume!
error: failed to update testing (error invoking external downloader)

And a similar set of messages for every repository.

Later, it went into a (practically) infinite loop, printing this:

error: could not open file /var/lib/pacman/sync/multilib-testing.db: Unrecognized archive format
error: could not open file /var/lib/pacman/sync/multilib-testing.db: Unrecognized archive format
error: could not open file /var/lib/pacman/sync/multilib.db: Unrecognized archive format
error: could not open file /var/lib/pacman/sync/multilib.db: Unrecognized archive format
error: could not open file /var/lib/pacman/sync/repo-ck.db: Unrecognized archive format
error: could not open file /var/lib/pacman/sync/repo-ck.db: Unrecognized archive format
error: could not open file /var/lib/pacman/sync/infinality-bundle.db: Unrecognized archive format
error: could not open file /var/lib/pacman/sync/infinality-bundle.db: Unrecognized archive format
error: could not open file /var/lib/pacman/sync/infinality-bundle-multilib.db: Unrecognized archive format
error: could not open file /var/lib/pacman/sync/infinality-bundle-multilib.db: Unrecognized archive format

a few hundred times (It went past my scrollback buffer of 2000 lines), and then showed the updated packages.

Pacman seems to run just fine.

I am using the following XferCommand line in my pacman.conf:

XferCommand = /usr/bin/axel -n 8 -a -v -o %o %u

The same issues occur when using wget.

However, I faced no issues when not using XferCommand.

Xyne · 2013-09-18 14:40:39

You need to properly quote the XferCommand. The default commands in pacman.conf make naive assumptions about URL formats.

Use one of the following

XferCommand = /usr/bin/curl -C - -f '%u' > '%o'
XferCommand = /usr/bin/wget --passive-ftp -c -O '%o' '%u'
XferCommand = /usr/bin/axel -n 8 -a -v -o '%o' '%u'

You can see the URL passed to pacserve by running (as root)

systemctl status pacserve.service

The format should be

/pkg/?repo=core&arch=x86_64&file=/core.db

. Without quoting, it only receives

/pkg/?repo=core

. I will add a note to the pacserve project page about this.

edit: The note has been added. To re-iterate, I strongly recommend using powerpill with Pacserve. It is much faster.

Last edited by Xyne (2013-09-18 14:47:53)

darnir · 2013-09-18 15:21:54

That worked. Thanks a lot!!
I'll go back and set up powerpill too.

Arch Linux

#126 2013-06-30 18:29:10

Re: pacserve - easily share Pacman packages between computers

#127 2013-06-30 20:44:41

Re: pacserve - easily share Pacman packages between computers

#128 2013-06-30 22:12:26

Re: pacserve - easily share Pacman packages between computers

#129 2013-06-30 22:53:41

Re: pacserve - easily share Pacman packages between computers

#130 2013-07-01 04:42:58

Re: pacserve - easily share Pacman packages between computers

#131 2013-07-01 05:04:35

Re: pacserve - easily share Pacman packages between computers

#132 2013-07-01 06:11:45

Re: pacserve - easily share Pacman packages between computers

#133 2013-07-01 06:28:07

Re: pacserve - easily share Pacman packages between computers

#134 2013-07-01 07:26:36

Re: pacserve - easily share Pacman packages between computers

#135 2013-07-01 08:37:47

Re: pacserve - easily share Pacman packages between computers

#136 2013-07-01 08:49:51

Re: pacserve - easily share Pacman packages between computers

#137 2013-07-01 09:35:28

Re: pacserve - easily share Pacman packages between computers

#138 2013-07-01 09:53:47

Re: pacserve - easily share Pacman packages between computers

#139 2013-07-01 09:58:57

Re: pacserve - easily share Pacman packages between computers

#140 2013-07-01 12:46:42

Re: pacserve - easily share Pacman packages between computers

#141 2013-07-01 19:29:05

Re: pacserve - easily share Pacman packages between computers

#142 2013-07-02 12:12:43

Re: pacserve - easily share Pacman packages between computers

#143 2013-07-02 19:18:03

Re: pacserve - easily share Pacman packages between computers

#144 2013-07-02 22:57:41

Re: pacserve - easily share Pacman packages between computers

#145 2013-07-03 00:10:44

Re: pacserve - easily share Pacman packages between computers

#146 2013-07-03 07:40:17

Re: pacserve - easily share Pacman packages between computers

#147 2013-07-03 21:08:04

Re: pacserve - easily share Pacman packages between computers

#148 2013-09-18 14:02:48

Re: pacserve - easily share Pacman packages between computers

#149 2013-09-18 14:40:39

Re: pacserve - easily share Pacman packages between computers

#150 2013-09-18 15:21:54

Re: pacserve - easily share Pacman packages between computers

Board footer