You are not logged in.
This forum is now blessed with a русский language option with your translations. Great!
Note that the forum software, including the translations (in their php form) is available at Devuan's gitlab.
That sounds good. I'll prepare the "translation pack" and email this to your registration email. It involves some 1500 phrases and 17 email templates. Though half or so are for the admin pages, which don't necessarily need translations.
@Eaglet: I you like, you would also be welcome to add the русский flavour to this forum.
Great work. I've lodged a bug on your behalf. https://bugs.devuan.org//cgi/bugreport.cgi?bug=222
Gems of knowledge into my sea of ignorance .. I hope the OP gets to mark this as solved soon.
Det låter jättebra. Tack. Låt mig samla ihop underlaget, så skickar jag det till din regestreringsadress (om en dag eller två).
There are probably many holes in my understanding, but isn't it so, that the server-vpn program already interacts on eth0 for handling its clients; so it's response packets are already outbound on eth0 without any routing?
Thanks
A full day without takers!
In my mind, "blame" is not central to Anarchism; there are other belief systems for that.
But I agree it's a good point: what would Kropotkin say?
mmm ... all 192.168.x.0/24 (ethX) traffic should go out without ado due to the network route.
That's a good set of rules for doing no filtering at all, yes ![]()
If you don't mind, rather dump the output if iptables-save, just to confirm all the tables. Basically, you shouldn't need any iptables rules, except the masquerading of the outbound traffic on tunY. That one is necessary to allow packets with original source from IP 10.8.x.0/24 (i.e., your server-vpn clients) or 192.168.y.0/24 (your wlanX neighbors), as well as allowing packets from 192.168.x.0/24 (your ethX neighbors) to be forwarded and masqueraded through tunY.
What would be the best way to check?
Remove the rule
iptables -A FORWARD -j REJECTto see if it works without it.
Then add it back, preceded by rules that allow forwarding between tunX and tunY.
Right. Some random googling suggests https://volumio.org/forum/vcgencmd-comm … html#p6319 to me, but you might have tried that already?
You might find something useful at https://www.syslinux.org/wiki/index.php?title=PXELINUX.
That Ubuntu solution is not right for Devuan.
However they suggest that hdparm -S is ineffective, and maybe that's the first thing to investigate. If it works fine, then the command
# hdparm -S 2 /dev/hdawould make the disk /dev/hda spin down after 10 seconds. Perhaps you can check that to begin with.
If that works, then the resume code path that leads to that (or the similar) command is broken, and we can look at that.
If not, then it's a more difficult problem.
If I understand it right, the basic tenet against a published Troll Count is on the line that it's more likely to be (mis-) used by a bunch of dickheads banding together to wield dickheadary against some normal adult member, than that it's used by the normal adult members as (weak) indicator towards the censoring of a dickhead.
Well, perhaps. I'll leave my head where it is for the moment.
Just to add some motivation:
My assertion is that when you are trolling, you are trolling whether you think so or not; it's not up to you, as a troll, to judge it right or wrong. Further, I believe some people would be too polite to nominate a troll if they thought the troll would see them doing it. They would rather suffer the trolling, and that would dull any edge of this extension.
The troll list is that little bit different from an ignore list in publishing the count, in the hope that it both stimulates people to evaluate the (perhaps) trolling posts more thoughtfully, and triggers self-criticism for the (somewhat) trolling poster.
You got it right. There is no way you can find out who are ignoring you (short of bribing me to tell you, of course).
Great! Dutch, or "Netherlands", is a new language for this forum, as is German ("Deutche"), so those tasks will involve the full grunt of translating some 1500 phrases, and 16 email templates.
I used to have a script that made a CSV for the phrases to make it easier But, as that was a couple of laptops ago, it'll take a short while to recall. When I've done so, and prepared the basis, I'll email it to your registration email address.
It reminds me that I'm still sitting still on the Swedish translation ![]()
Perhaps one of you could spell out a way in which this might be abused, or rather I assume, a way in which this function can be used to abuse someone?
Is it that you think, that by X seeing an elevated troll count for Y, they (X) would be more inclined than otherwise to also nominate Y as troll? Or that Y would be unhappy seeing that so many members see them as a troll?
If Y is trolling in the eyes of some/many, then Y is trolling in the eyes of some/many, whether Y thinks so or not.
Without feedback, Y won't learn or change.
Package locales seems to be the owner of /etc/locale.gen (or at least the man page).
I think you're using the url tag back-to-front; it takes the actual url in the begin tag, and the description between the tags. So if you swap those, it becomes a click-accessible url. As is, one has to copy that url that is seen and paste to follow, rather than clicking it.
devuser might be right, though one thing is that you do need to allow forwarding between tunX and tunY.
server-vpn might keep its clients up-to-date with its own gateway, which changes from 192.168.x.1 to be 10.8.y.1. It thus configures its clients' routing to pass 10.8.y.1 traffic through itself, and that traffic would stop at the forwarding block.
Yes, forget my nonsense about masquerading on the output chain, and check routing regarding the ethX network. In particular, the server-vpn return traffic must not be routed through the client-vpn.
I think, since those are locally generated but with remote sources, you'll also need a MASQUERADE rule on the OUTPUT chain of the nat table. I suppose the set up of the first openvpn (the server) should have dealt with it, but it perhaps worked out to use something else (eth0) as its outbound interface. In fact, maybe a restart of the server, after the outbound openvpn (client) is set up makes this happen?
Could it be that the outbound traffic through tunY needs NAT (i.e. a MASQUERADE rule)?