<div><div dir="auto">Thanks Roland for your suggestions, they were very helpful. </div><div dir="auto"><br></div><div dir="auto">Just a side note, tested your docker image from dockerhub (linbit/coccinelle), but it appears to be slightly outdated (it&#39;s on 1.0.7).</div></div><div dir="auto">To be honest, the tarball method works fine for me, but having also the docker image up to date would be helpful.</div><div dir="auto"><br></div><div dir="auto">B.R.</div><div dir="auto">G.</div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 9 Dec 2019 at 09:16, Roland Kammerer &lt;<a href="mailto:roland.kammerer@linbit.com">roland.kammerer@linbit.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Dec 08, 2019 at 09:00:09AM +0000, Gianni Milo wrote:<br>
&gt; Hi Christoph,<br>
&gt; <br>
&gt; I followed your suggestions and below follows the outcome of it...<br>
&gt; <br>
&gt; - I&#39;m using DRBD9 on Proxmox, which in turn its based on Debian 10, so the<br>
&gt; PPA method did not work as it&#39;s designed for Ubuntu?<br>
<br>
Yes. <a href="https://wiki.debian.org/DontBreakDebian" rel="noreferrer" target="_blank">https://wiki.debian.org/DontBreakDebian</a> . Don&#39;t mix in PPAs if you<br>
do not exactly know why.<br>
<br>
&gt; - Debian 10 ships with an old spatch version (1.0.4), where DRBD requires<br>
&gt; 1.0.8, so no luck there as well.<br>
<br>
Also true.<br>
<br>
&gt; -Only solution for Proxmox users seem to be using SPAAS method and that<br>
&gt; works, as soon as Proxmox servers have unrestricted access to the internet.<br>
&gt; In our topology that&#39;s not the case, as these servers cannot access<br>
&gt; internet hosts on non standard ports.Your SPAAS service requires access to<br>
&gt; the port TCP 2020. Would it be possible to use a fallback port TCP 443 or<br>
&gt; TCP 80 instead ?<br>
<br>
I think about it. Currently we host it on a server that already uses<br>
80/443 for something else.<br>
<br>
&gt; - One last method, which also seems to work is  by using a separate machine<br>
&gt; (or VM), with Proxmox installed and with unrestricted access to the<br>
&gt; internet. Build DRBD kernel modules in there (with SPAAS) and manually<br>
&gt; transfer them  to the production servers (in<br>
&gt; /lib/modules/&lt;kernel_version&gt;/updates).<br>
<br>
One additional way would be to extract the tarball on a machine you can<br>
access SPAAS and where you have the exact same kernel version as on the<br>
destination. Then build it, which will fetch a SPAAS generated patch.<br>
Then generate the dkms package from that and dpkg -i it. This then finds<br>
the patch in the cache and does not try to fetch it. Not very nice, just<br>
saying it could be done like this.<br>
<br>
What some devs, me included, did for some time was to use a &#39;spatch&#39;<br>
that was in fact a Docker container containing an spatch recent enough.<br>
You most likely don&#39;t want that in production either, but it could be<br>
used instead of SPAAS for the above described tarball-repacking.<br>
<br>
Best, rck<br>
_______________________________________________<br>
Star us on GITHUB: <a href="https://github.com/LINBIT" rel="noreferrer" target="_blank">https://github.com/LINBIT</a><br>
drbd-user mailing list<br>
<a href="mailto:drbd-user@lists.linbit.com" target="_blank">drbd-user@lists.linbit.com</a><br>
<a href="https://lists.linbit.com/mailman/listinfo/drbd-user" rel="noreferrer" target="_blank">https://lists.linbit.com/mailman/listinfo/drbd-user</a><br>
</blockquote></div></div>