e /etc/systemd/system/minissdpd.service.d/override.conf
Copy /lib/systemd/system/minissdpd.service to
/etc/systemd/system/minissdpd.service.
Edit the resulting file.
Reco
Hi.
On Sun, Mar 10, 2019 at 05:13:35PM +, Joe wrote:
> On Sun, 10 Mar 2019 19:35:18 +0300
> Reco wrote:
> > On Sun, Mar 10, 2019 at 04:32:42PM -, Curt wrote:
> >
> > >
> > > I thought he was saying the surest approach is not touchin
contains a mounted filesystem.
>
> ==> mkfs /dev/sdh1
> works
>
> any explanation?
/sbin/mkfs calls a different binary, /sbin/mkfs.ext2.
Different utility does different checks.
Reco
Hi.
On Sun, Mar 10, 2019 at 04:32:42PM -, Curt wrote:
> On 2019-03-10, Richard Owlett wrote:
> > On 03/10/2019 10:20 AM, Reco wrote:
> >>Hi.
> >>
> >> On Sun, Mar 10, 2019 at 10:58:12AM -0400, deb wrote:
> >>> Starting
d kludges (in the form of anti-virus) around it,
it's considered wise here to use a secure OS from the beginning.
Reco
n this
particular case.
> Perhaps I'm missing something here.
network-online.target does not guarantee that specific network
interfaces will be present.
For instance, enp7s0 can be configured instantly (static IP assignment),
wlp6s0 can lag behind it (dhcp assignment).
Reco
Hi.
On Sat, Mar 09, 2019 at 09:27:35PM -0500, Default User wrote:
> On Sat, Mar 9, 2019 at 2:45 AM Reco wrote:
> >
> > On Fri, Mar 08, 2019 at 04:00:05PM -0500, Default User wrote:
> > > Hi. Got a (minor) systemd problem.
> > ...
> > >
a dependency in the form of:
[Unit]
After=sys-subsystem-net-devices-enp7s0.device
sys-subsystem-net-devices-wlp6s0.device
Requires=sys-subsystem-net-devices-enp7s0.device
sys-subsystem-net-devices-wlp6s0.device
Should help with the issue.
Reco
Hi.
On Fri, Mar 08, 2019 at 09:34:03AM +, Jonathan Dowland wrote:
> On Tue, Mar 05, 2019 at 06:10:40PM +0300, Reco wrote:
> > s/RedHat/IBM/g
> >
> > fixed that for you.
>
> Not until the deal closes, because there's still a small chance it
> won't (a
ks!
Start ssh server on 192.168.1.3, or modify iptables REJECT rule on
192.168.1.3 that prevents you to access tcp:22.
There are two way to interpret "Connection refused" message, and both
do not have anything in common with ssh server settings.
Reco
On Wed, Mar 06, 2019 at 03:32:02PM +0100, Dejan Jocic wrote:
> On 06-03-19, Reco wrote:
> > Hi.
> >
> > On Wed, Mar 06, 2019 at 12:17:27PM +0100, Dejan Jocic wrote:
> > > On 05-03-19, Reco wrote:
> > > >
> > > > Canonical's famous for the
Hi.
On Wed, Mar 06, 2019 at 12:17:27PM +0100, Dejan Jocic wrote:
> On 05-03-19, Reco wrote:
> >
> > Canonical's famous for their NIH too. Mir, Unity, LXD - it's a long
> > list, although RedHat has longer one.
> >
> > Reco
>
>
> Mir and
Hi.
On Tue, Mar 05, 2019 at 05:07:00PM +0100, to...@tuxteam.de wrote:
> On Tue, Mar 05, 2019 at 06:10:40PM +0300, Reco wrote:
> > Hi.
> >
> > On Tue, Mar 05, 2019 at 02:26:24PM +0100, plataleas plataleas wrote:
> > > Hi all
> > >
> >
no sensible program should take.
> Does it make sense to prefer podman/buildah/skopeo over the docker
> engine on Debian systems as well?
I'd suggest runc if you're looking for a viable alternative right now.
Reco
[1] https://www.docker.com/products
On Fri, Mar 01, 2019 at 07:34:50PM +0100, Pascal Hambourg wrote:
> Le 01/03/2019 à 18:56, Reco a écrit :
> >
> > First, there's huge amount of unused (not to be confused with "free")
> > memory on your host. And no, it's not a filesystem's cache (600M), it's
&g
> > a non-essential disk to make the system drop to single user on boot.
>
> Yup. `nofail` corresponds to the behavior that was standard
> before systemd.
... in Debian. That part of systemd was inherited from Red Hat's
interpretation of "proper OS booting".
Reco
Hi.
On Fri, Mar 01, 2019 at 02:39:22PM -0300, Bruno Schneider wrote:
> On Fri, Mar 1, 2019 at 2:18 PM Reco wrote:
> >
> > Please post the contents of /proc/meminfo. And "sar -r ALL 1 10", for
> > the sake of the completeness.
>
> $ cat /proc/
10042303 63 573
> 2598
> Swap: 956 239 717
>
> Can anyone help find the reason / prevent it?
Please post the contents of /proc/meminfo. And "sar -r ALL 1 10", for
the sake of the completeness.
To prevent it:
sysctl -w vm.swappiness=0
Reco
Hi.
On Tue, Feb 26, 2019 at 11:12:43PM -0800, Rusi Mody wrote:
> Reco wrote:
> Running parted on a logical volume is definitely not the best of ideas
>
> Sure!
>
> My point was however that for a tool (eg gparted) where label already has the
> LABEL= sense
e type", like "msdos"
or "gpt" or "sun".
Running parted on a logical volume is definitely not the best of ideas.
Reco
alsa, evolution - basically anything that's either shipped with
DE, or written with "Modern App" approach in mind.
> I'd also point out that, at least in Alpine, the feature does not depend
> on or require the use of an external MTA such as sendmail, Exim, etc.
mutt's happy to bounce without /usr/bin/sendmail too.
Reco
Hi.
On Fri, Feb 22, 2019 at 10:52:37AM +, Jonathan Dowland wrote:
> The same result can be achieved with a procmail recipe, or a shell
> script, if you have access to the raw mail.
... and if you do not - you're not using a proper e-mail client anyway.
Reco
ompletely useless.
> I can imagine that one could try to use kernel tracing here but that
> would be a huge hammer.
"perf trace" could work for you.
Attaching to a getty via gdb could work too, but it'll likely screw the
login process.
Reco
sion of wait-connect all
But that's hackish approach at best.
Reco
ocal_fs $network $syslog
Change them:
# Required-Start: $local_fs $network $syslog open-iscsi
# Required-Stop: $local_fs $network $syslog open-iscsi
And invoke "systemctl daemon-reload".
Reco
estored.
PS I should watch who I'm replying to.
Reco
they either made ping root-owned suid, or assigned CAP_NET_RAW
capability to it (that's stretch btw):
$ /sbin/getcap /bin/ping
/bin/ping = cap_net_raw+ep
So, run /var/lib/dpkg/info/iputils-ping.postinst (or whatever iputils
alternative you have installed), and enjoy sanity restored.
Reco
Hi.
On Thu, Feb 21, 2019 at 05:29:56PM +0100, Hans wrote:
> Am Donnerstag, 21. Februar 2019, 16:46:42 CET schrieb Reco:
> Yes, worked. However, I did not find any unusual, however, putting a stick in
> is starting "colord-sane", which will explain the UDP req
ogin.defs) to find out what that is...
>
> ... hey, where's the buster man pages?
Exactly there they belong. In .deb archives.
Reco
t/audit.log.
Red Hat documentation at it's finest.
Reco
Hi.
On Thu, Feb 21, 2019 at 08:43:47AM -0500, Gene Heskett wrote:
> On Thursday 21 February 2019 08:32:18 Reco wrote:
>
> > Hi.
> >
> > On Thu, Feb 21, 2019 at 08:21:00AM -0500, Gene Heskett wrote:
> > > On Thursday 21 February 2019 03:59:37 to...
Hi.
On Thu, Feb 21, 2019 at 08:20:46AM -0500, Greg Wooledge wrote:
> On Thu, Feb 21, 2019 at 09:31:31AM +0100, Pierre Couderc wrote:
> > On 2/21/19 9:15 AM, Reco wrote:
> > > On Thu, Feb 21, 2019 at 09:07:09AM +0100, Pierre Couderc wrote:
> > > > Why /us
Hi.
On Thu, Feb 21, 2019 at 08:21:00AM -0500, Gene Heskett wrote:
> On Thursday 21 February 2019 03:59:37 to...@tuxteam.de wrote:
>
> > On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:
> >
> > [...]
> >
> > > You can also help us by bouncing
Hi.
On Thu, Feb 21, 2019 at 11:42:58AM +0100, Hans wrote:
> Am Donnerstag, 21. Februar 2019, 11:19:08 CET schrieb Reco:
> Hi Reco (and all others),
>
> sure, I attached the wireshark pcap. Thre is nothing secret in it.
That's interesting. Aforementioned pcap does not co
72]: attackalert:
> Connect from host: 192.168.2.117/192.168.2.117 to UDP port: 161
So it's a local SNMP connection, if I get it right?
Reco
m to
report-lists...@lists.debian.org
It's my understanding that bouncing to [3] should be ok.
> [1] https://wiki.debian.org/Teams/ListMaster/FAQ
> [2] mailto:listmas...@lists.debian.org
> [3] mailto:report-lists...@lists.debian.org
Reco
's environment unless '-' is specified is a feature of
util-linux's su.
Reco
uncing to the list.
If you want to notify listmaster team about spam, you should bounce to [2].
> debian shoulda rejected it in the first place.
And you can help this by reporting an offending e-mail as spam, see [1].
Reco
[1] https://wiki.debian.org/Teams/ListMaster/FAQ
[2] mailto:listmas...@lists.debian.org
ews are - the solution is on its way.
Reco
Hi.
On Sun, Feb 17, 2019 at 06:10:41PM +0100, Siard wrote:
> Reco:
> > Siard:
> > > Patrick Bartek:
> > > > Juan R. de Silva:
> > > > > Patrick Bartek:
> > > > > > Claws-mail besides being a text-based only email client can
il is subscribe.
>
> Your headers, however, indicate that you follow it through newsgroup
> gmane.linux.debian.user.
Can you elaborate which SMTP headers in particular led you to this
conclusion please?
Because all I saw in that e-mail was pretty typical for GMail user using
Claws-Mail as MUA.
PS Mutt and headers editing. Need to be more careful next time.
Reco
usion please?
Because all I saw in that e-mail was pretty typical for GMail user using
Claws-Mail as MUA.
Reco
Hi.
On Fri, Feb 15, 2019 at 10:14:10PM +0100, Pascal Hambourg wrote:
> Le 15/02/2019 à 17:48, Reco a écrit :
> >
> > Why it is safe - because systemd configures NICs first, starts services
> > next, and then applies kernel knobs (aka sysctl).
>
> Are you sure
.conf << EOF
#Type Path Mode UID GID Age Argument
d /run/cyrus0755 cyrus lmtp - -
d /run/cyrus/socket 0750 cyrus lmtp - -
EOF
And you have to dpkg-divert /usr/lib/tmpfiles.d/cyrus-imapd.conf if
you're *not* using systemd, see above.
Reco
Hi.
On Fri, Feb 15, 2019 at 11:17:06AM -0500, Felix Miata wrote:
> Reco composed on 2019-02-15 19:02 (UTC+0300):
>
> > On Fri, Feb 15, 2019 at 10:55:23AM -0500, Felix Miata wrote:
>
> >> To me, "on boot" implies something on the kernel cmdlin
Hi.
On Fri, Feb 15, 2019 at 10:55:23AM -0500, Felix Miata wrote:
> Reco composed on 2019-02-15 18:23 (UTC+0300):
>
> > On Fri, Feb 15, 2019 at 10:13:14AM -0500, Stephen P. Molnar wrote:
>
> >> Thanks for help from this gropup I can force the use of IPv4 by r
'net.ipv6.conf.all.disable_ipv6 = 1' > /etc/sysctl.d/noipv6.conf
Reco
On Mon, Feb 11, 2019 at 03:55:04AM +1100, Andrew McGlashan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> On 10/2/19 11:17 pm, Reco wrote:
> >> Okay, I've watched it now. I am not convinced that his idea of
> >> "creat
Hi.
On Sun, Feb 10, 2019 at 01:48:35PM +, mick crane wrote:
> On 2019-02-10 12:17, Reco wrote:
>
> > No. See SCO vs IBM case. Linux is not Unix, and never has been.
>
> wasn't it IBM gave Minix away and Torvalds used that as a base ?
But it wasn't enough to make
ver has been.
> It is a pity that Oracle has their licensing problems in relation to
> ZFS
Please blame Sun Microsystems for *that*. Oracle's merely keeping the
status-quo.
> and there are great alternative implementations now;
You mean, ZFS-on-Linux? It's a fork of OpenSolaris' ZFS implementation,
not something that's written from scratch.
Reco
If not, they are useless for booting and can be removed just as they
created.
Reco
Setting this theme systemwide is left as an exercise for the readers.
Reco
gt; >
> > > Cheers
> > > -- t
> > You're trying to access it from a .de domain? Probably blocked, although
> > I was alerted by a NY resident who wasn't blocked.
>
> I'd guess the same. But... now it gets interesting: blocked by whom?
> China? North Korea?
Site owner, of course. (No)thanks to GDPR, it's easier for US site to
block any visitor from Europe than to comply with legal regulations.
Reco
Hi.
On Thu, Jan 31, 2019 at 09:50:14PM -0800, X200 wrote:
> fingerprint enrolling passes successfully with super user, but does not ask
> to swipe finger when "su" command executed.
Do you have "libpam-fprintd" installed?
What are the contents of "/etc/pam.d/common-auth"?
Reco
protocol libraries include
> copies of the RFCs they implement and those RFCs are sometimes not
> freely redistributable).
>
> I have yet to encounter a "dfsg" repack that changes the functionality
> of the package, though.
dfsg repack of snmpd, for instance. Running the thing without upstream
MiBs is a pain. Yes, they provide a way to get those MiBs, but still.
Reco
On Sun, Jan 13, 2019 at 02:22:09PM +0100, Tom Bachreier wrote:
>
> Hi Reco!
>
> Jan 13, 2019, 1:47 PM by recovery...@enotuniq.net:
>
> > On Sun, Jan 13, 2019 at 01:20:50PM +0100, Tom Bachreier wrote:
> >
> >> Jan 13, 2019, 12:46 PM by >> recov
Hi.
On Sun, Jan 13, 2019 at 01:20:50PM +0100, Tom Bachreier wrote:
>
> Hi Reco!
>
> Jan 13, 2019, 12:46 PM by recovery...@enotuniq.net:
>
> > On Sun, Jan 13, 2019 at 12:27:19PM +0100, Tom Bachreier wrote:
> >
> >> TLDR;
> >> My /home
how I can debug this issue further? Is it a dmcrypt,
> a dm-softraid or a hardware issue?
Let's start with something uncommon:
for x in /dev/sd{b..f}; do
smartctl -l scterc $x
hdparm -J $x
done
Reco
that's I've lost interest to like 10 years ago.
On the bright side - it built, so at least something has gone according
to the plan.
Reco
quot;);
>~~^~~~
> game/StimResponse/StimResponseTimer.cpp:23:61: error: dereferencing a
> null pointer in ‘*0’
No, I'd remember those. My 2.06 does not have these asserts at all:
$ grep -c assert thedarkmod/game/StimResponse/StimResponse.cpp
0
Reco
ing facility (such
as BPF) for that.
Reco
ms/proc.txt.gz from the kernel documentation.
kernel source tree.
Reco
# data
auto eno1.7
allow-hotplug eno1.7
iface eno1.7 inet dhcp
metric 32
iface eno1.7 inet6 auto
accept_ra 0
Reco
dynamic, limited address lifetime).
And you don't need anything but a Linux kernel to get it.
If you don't need IPv6 on that interface for some reason - add the
following to your /etc/network/interfaces:
iface enp1s0 inet6 auto
accept_ra 0
Reco
Hi.
On Tue, Jan 08, 2019 at 02:56:39PM -0600, Richard Owlett wrote:
> I wish to feed the output of "lsblk -l -o name,label" to a script which
> *DEPENDS* on input being in strict alpha-numeric order.
>
> How?
lsblk(8):
lsblk -l -x name -o name,label
Reco
mp/02-ffmpeg.patch
3) Building:
scons BUILD="release" TARGET_ARCH="x64" -j`nproc`
Of course, doing it the proper way (unbundling all the libraries, fixing
signed/unsigned mixups, etc), wrapping the thing into a package - is
outside of scope of this mini-howto.
Reco
On Sat, Jan 05, 2019 at 11:16:23AM +0100, hdv@gmail wrote:
> On 05/01/2019 08.52, Reco wrote:
> > Hi.
> >
> > On Sat, Jan 05, 2019 at 03:41:05AM +0100, hdv@gmail wrote:
> >> So how do I make sure that 4.18.0-2 does not get removed from the boot menu
>
4.18.0-2-amd64
Reco
Hi.
On Fri, Jan 04, 2019 at 11:03:48PM -0500, rhkra...@gmail.com wrote:
> On Friday, January 04, 2019 08:23:59 AM Reco wrote:
> > # pvs
> > PV VG Fmt Attr PSize PFree
> > /dev/md10 naslvm2 a-- 14.55t 10.43t
> >
> > # h
nds = 384.42 MB/sec
I see a difference, but I's something I can live with.
Reco
r removing them or moving them elsewhere. If it's just data
> > then it looks like somewhere under /home would be a good choice as
> > it has 292G available.
> >
> > Ask before deleting anything you don't fully understand.
>
> 1. First assess what the space on / is allocated to.
>
>du -hs /lib/
>du -hs /etc/
>du -hs /usr/
>du -hs /usr/bin/
>du -hs /usr/local/
du -xh / | sort -h
Why bother typing several commands if you can type one?
Reco
0, 147456
kb/s, 30 fps, 30 tbr, 1000k tbn, 1000k tbc
I prefer mpv for this, but ffplay works too.
Since you're getting a SIGSEGV, you may have to follow the usual
routine: get a coredump, extract a backtrace with gdb, fill a bugreport.
Reco
Hi.
On Wed, Jan 02, 2019 at 02:56:41PM -0500, Miles Fidelman wrote:
> some of the recent politics, has made me far less comfortable that Debian
> will remain a stable platform - and I'm seriously considering migrating to
> either Gentoo or a BSD platform.
LOL, you've made my day, sir.
houldn't need to shut down the machine, actually. X11 has
> > had hot input switching since about that time period.
>
> Old machines would sometimes freeze if you yanked the PS/2 keyboard.
And you can fry PS/2 port permanently by hotplugging.
Did it twice personally.
Reco
Hi.
On Wed, Jan 02, 2019 at 01:34:14PM +0100, Andrea Borgia wrote:
> Il 02/01/19 12:15, Reco ha scritto:
>
> > What about this:
> > DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ \
> > sh -x /lib/udev/hdparm >> /tmp/hdparm.log
A7A384E2024242DBNGWJ_
I suspect that your problem cannot be explained by hdparm bug.
Reco
each 12 hours
>
> Should I report bug and where? I always have pain to understand Xorg
> organization.
There's no need to - see #900717.
According to [1], the following xorg.conf should help with the issue:
Section "Device"
Driver "modesetting"
Option
non-managed switch outside of your
'virtualization server'. Oh, and disabling STP (just as your link
'helpfully' suggest) can lead to even more funny results.
Reco
Hi.
On Sat, Dec 29, 2018 at 06:40:57PM -0500, Gary Dale wrote:
> Any suggestions?
Keep your bonding as it is.
Forget about conventional Linux bridges, and do not use them ever.
Reconfigure your virtual machines to use macvtap (like suggested here -
[1]), you'll need 'bridge' mode.
R
Hi.
On Sat, Dec 29, 2018 at 03:26:48PM -0600, John Hasler wrote:
> Reco writes:
> > Or, in this particular case, follow "good old"
> > configure-make-make_install pattern.
>
> Nothing wrong with that as long as you install in /usr/local and realize
> th
On Sat, Dec 29, 2018 at 04:12:53PM -0500, Roberto C. Sánchez wrote:
> On Sat, Dec 29, 2018 at 11:06:37PM +0300, Reco wrote:
> > On Sat, Dec 29, 2018 at 02:40:41PM -0500, Roberto C. Sánchez wrote:
> >
> > > while people paying $$$ for RHEL support
> > >
tic transitions (e.g., the one involving
> udev was a good example)
That's a *very* x86-centric POV.
For instance, whoever came up with the idea of disabling
CONFIG_COMPACTION on armel/kirkwood between jessie and stretch rendered
armel ununsable on stretch.
And let's do not mention kfreebsd.
Reco
down ip -4 route delete default via 172.18.8.1 dev eth0 table 10
down ip -4 route delete 172.18.8.0/24 dev eth0 table 10
down ip -4 rule delete from 172.18.8.211/32 table 10
down ip -4 link set dev eth0 nomaster
down ip -4 link del mgmtvrf
post-down sysctl -qw net.ipv4.tcp_l3mdev_accept=0
Reco
set).
# This is useful if MPD needs to be a member of group such as "audio" to
# have permission to use sound card.
My suspicion is that mpd simply discards membership of 'audio' group
then run as a daemon.
So, try this /etc/mpd.conf:
group "audio"
audio_output {
type"alsa"
name"ALSA sound card"
}
Reco
On Mon, Dec 24, 2018 at 04:27:31PM -0500, Default User wrote:
> On Mon, Dec 24, 2018, 15:47 Reco
> > On Mon, Dec 24, 2018 at 09:58:19AM -0500, Default User wrote:
> > > On Mon, Dec 24, 2018, 05:20 Ivan Ivanov > >
> > > > >500 comments at Slashdot, >
re or its removal at debian-user (a hint -
there's debian-ctte for this)
Reco
d.log
:msg, contains, "DHCPOFFER" /var/log/dhcp/dhcpd.log
:msg, contains, "DHCPNAK" /var/log/dhcp/dhcpd.log
:msg, contains, "DHCPINFORM" stop
:msg, contains, "DHCPACK" stop
:msg, contains, "DHCPREQUEST" stop
:msg, contains, "DHCPOFFER" stop
:msg, contains, "DHCPNAK" stop
Everything that's listed in that file goes to /var/log/dhcp/dhcpd.log
only.
Everything that's not listed there is processed by other rsyslog rules.
Reco
wrote:
> Hi again Reco.
>
> What would be the best way to "blacklist"
> /lib/udev/rules.d/73-usb-net-by-mac.rules?
Execute this as a root, verbatim:
touch /etc/udev/rules.d/73-usb-net-by-mac.rules
update-initramfs -k all -u
Reco
ken' the same way.
> but I have NO IDEA what package to mention
Network Manager, of course. Unless you can prove (with a simple
reproducible wpa_supplicant/iproute combo) otherwise.
Reco
Hi.
On Fri, Nov 30, 2018 at 11:05:19PM +0100, arne wrote:
> On Sat, 20 Oct 2018 10:27:19 +0300
> Reco wrote:
>
> > > > > Any ideas what can be the solution?
> > > >
> > > > A better question would be - what's the actual problem.
>
it
should do.
Reco
Hi.
On Wed, Nov 28, 2018 at 10:20:22PM +0100, Patrice Duroux wrote:
> root@hp-dark:/var/lib/systemd/coredump# gdb
> core.tracker-extract.1000.273d78802abc412f8e7a360fd7509e52.14743.154343689200
It's always 'gdb '.
Reco
md/system/certbot.service /etc/systemd/system/certbot.service
$EDITOR /etc/systemd/system/certbot.service
systemctl daemon-reload
Reco
n eth0 and tun0,
but that's wrong on so many levels that I don't know where to begin to
describe it.
In conclusion, your current NAT66 setup is probably the best you can
achieve without a risk to your VPS or your sanity ;)
Reco
Hi.
On Tue, Nov 27, 2018 at 01:20:25PM +0100, tony wrote:
> On 27/11/2018 12:44, Reco wrote:
> > Hi.
> >
> > On Tue, Nov 27, 2018 at 12:26:03PM +0100, tony wrote:
> >> OK, that fixed it, thanks. Almost there. I had expected the host's
> >>
.com @resolver1.opendns.com
> 2a03:9800:10:54::2
>
> Is that fixable?
Probably. My suspicion is that openvpn has configured NAT66 for you,
along with the routing.
Can I see the result of "ip6tables-save" from your openvpn server?
Reco
On Tue, Nov 27, 2018 at 11:53:07AM +0100, tony wrote:
> On 27/11/2018 11:43, Reco wrote:
> > Hi.
> >
> > On Tue, Nov 27, 2018 at 11:19:12AM +0100, tony wrote:
> >>>> push "route-ipv6 2a03:9800:10:54:8000::/65"
> >>>> push "r
:/0 address, nor do I understand that.
Nah, it does not like "metric" part, which is crucial here.
But try this:
push "redirect-gateway def1 ipv6"
> Please indulge my ignorance a little longer; I feel we're getting there.
Sure. One cannot learn unless one's doing.
Reco
: No such file or directory
Assuming that's a 'system' service:
systemctl stop tracker-store.service
systemctl mask tracker-store.service
But if it's the 'user' service, you have to do:
systemctl --user stop tracker-store.service
systemctl --user mask tracker-store.service
Reco
tun
L3 tunnel, eh? A good choice, if you ask me.
> push "route-ipv6 2a03:9800:10:54:8000::/65"
> push "route-ipv6 2000::/3"
> push "redirect-gateway def1 bypass-dhcp"
Remove these. Use this instead:
push "redirect-gateway def1"
push "route-ipv6 ::/0 metric 99"
Reco
901 - 1000 of 2347 matches
Mail list logo
