You are not logged in.
ok ... seems to lead out of my comfort zone. The product id (0x094b) is not listed in http://www.linux-usb.org/usb.ids, and afaict it's also not among the entries for libmtp (http://libmtp.sourceforge.net/).
So it appears that making it work is slightly more than plug-n-play. I'm not aware of any possible shortcut, but maybe someone else knows better.
That device, 054c:094b, does not appear to yet be listed among known devices, but it might work by identifying it explicitly for jmtpfs, i.e. if your mount point is /media/camera you'd use:
jmptfs -d 001,003 /media/cameraPerhaps it needs exfat-fuse (and maybe exfat-utils) whcih I don't think are installed by default.
Perhaps jmtpfs works for you.
@bbatten: iptables on beowulf (or buster, really) doesn't require arptables or ebtables, but it recommends nftables.
Upon installation, it gets set up to use the iptables-nft alternative implementation and then it provides syntax transparency via /usr/sbin/xtables-nft-multi so as to use the "traditional" iptables rules language for manipulating and reviewing the rules.
It also gives you the option to change it to use the iptables-legacy implementation through update-alternatives.
Doesn't that work for you?
You might also want to reinstall iptables without nftables; perhaps something like
# apt-get install --reinstall nftables- iptablesThat should give you a set up that allows the "normal" iptables rules.
💁 ... someone just made this forum full utf8... enjoy
https://unicode.org/emoji/charts/full-emoji-list.html
@gu_1: as was indicated by @Head_on_a_Stick the domain name br.deb.devuan.org resolves to the domain name pkgmaster.devuan.org which is Devuan's own repository server and not to the round-robin domain name deb.devuan.org.
Thus, by using br.deb.devuan.org you don't take advantage of any mirroring, and always get packages served by pkgmaster.devuan.org.
Whilst that is fine for any individual case, it's something we generally want people to avoid doing, since it accumulates into a reduced service for everyone. Therefore the advice is that you should really use deb.devuan.org.
If you do want to use some particular server, or a subset of the round-robin servers, then the way to go is to edit your /etc/hosts to resolve deb.devuan.org to that server/subset. For example, you might add these lines to /etc/hosts:
# My preferred package sources
192.80.24.194 deb.devuan.org devuan.dcc.uchile.cl
200.236.31.1 deb.devuan.org devuan.c3sl.ufpr.br
2801:82:80ff:8000::2 deb.devuan.org devuan.c3sl.ufpr.brThose particular lines would make apt use only the two servers devuan.dcc.uchile.cl and devuan.c3sl.ufpr.br as package sources (for ipv6, only the latter). (see man hosts for details about /etc/hosts)
Note: you may refer to https://pkgmaster.devuan.org/mirror_list.txt to find out which servers are in the round-robin, and you may use the host or dig commands to determine their IP addresses.
Devuan has a system in place to monitor round-robin servers with respect to their Devuan package service. You find graphs detailing status e.g. at http://veritas.devuan.org/apt-panoptico … pticon_cgp.
Yes;
afaiui there is a hotplug event generated when the "kvm subsystem" (Kernel-based Virtual Machine) has been initialized. That event is (like all) handled by the hotplug handler (aka udev/eudev) via that "rule", which directs the handler to create the device node "/dev/kvm" with the particular permissions and group.
The same actions by hand would be these:
# mknod /dev/kvm c 10 232
# chmod 0666 /dev/kvm
# chgrp kvm /dev/kvmCommenting out the rule will result in the absence of the device node, but not the sub system itself of course. This should be fine until there's some software needing it; eg qemu or virtualbox or whatever. Under an ideal modularization principle, the device node would rather be created as needed by that software, but few things are ideal.
To avoid the complaint and be without a "kvm" group, some surgery of /lib/udev/rules.d/50-udev-default.rules might be sufficient; perhaps just removing the GROUP="kvm", bit, or that whole line, whichever feels more pleasing. The effects would be either that a /dev/kvm device node gets created with group root without complaint, or that it doesn't get created at all.
I should apologise for suggesting that anyone here would be "an idiot". It's an unnecessarily offensive labelling which I don't think should be applied to any contributor. I did use it, but merely as a "literary short cut" to emphasize my view about certain ways of acting on this forum; namely that of deleting and/or destroying ones previous posts. However, it was not meant to be a value judgement against anyone's contribution(s), in the past or in the the future.
Now, due to my praiseworthy effort, that way of acting is no longer possible. Well rather, it is now a restricted ability available only to those who sports the role of Administrator, as well as of course, to those who have access to the server.
I see that @Vernon, and probably others, think of this differently from me. Since we (including me) want this to be a forum that in principle is owned by its contributors, I will want to pursue this discussion a bit to understand what the difference is. Especially if I am supposed to dive into the code again to make a variation or retraction of my improvements.
My start point was that I see all threads and posts as valuable, and therefore it should not be available for posters to change or delete their posts once they've made them, except for a grace period for the purpose spelling and grammar corrections. Perhaps it should even be stronger than now; that deletion should only be available until there is a subsequent post.
Maybe this is influenced by mailing lists which have that nature.
I don't think the idea of saving threads elsewhere ("if someone in the community feels a thread is valuable") is a workable approach, because I think this site is supposed to be that archive of Devuan-related discussions. That is indeed the reason why changing posts to me is outside of agreeable activity.
What else is this forum if not an archive of Devuan-related discussions?
@Vernon, firstly I don't think a discussion site becomes a wiki site merely by claiming that it is one.
In parenthesis, there is work in progress towards a Devuan wiki site, and that should hopefully cater for those kinds of contributions. At that time we might even find or proclaim that a discussion site is an uninteresting extra and close it down, or we might not, and continue.
Secondly, a suggestion that implies more administrator work is only taken seriously (by me) if the suggester also at the same time volunteer for taking on that work. (Actually, it is due time for this site in full to move into new hands [out of my hands]... but that is a separate discussion)
Another secondly, your statement
No one is asking for editing history, just the ability to edit their own posts indefinitely.
doesn't fare well in a semantic analysis. Specifically, "edit their own posts indefinitely" is an example of "editing history".
I am guessing that you rather want to suggest that noone will, if editing is allowed, change their posts in a "bad way" with respect to the interest of the community. Or perhaps more likely, that you want to suggest the benefit of allowing such editing well outweighs the risk of communal loss by (a few) idiots "misbehaving".
At present we administer this forum as a "public discussion forum".
This means in particular that the posts are contributions to the thread(s) of discussion in as much is possible similar to verbal group discussion. In particular we cannot un-say what is said. Rather, if I mis-speak in a way I see as significant, I'll have to make further contributions to correct, revise or retract that mis-speaking. In short, the posts I make are not "mine to edit"; after I've make a contribution it thereafter remains as the contribution I made at the time.
As a matter of contrast, this site is (was) not intended to be a "personal blogs site" or "dokumentation site" (aka wiki), although a number of threads are laid up more like such than as public discussions. And at least in my mind, "editing history" is not a feature of a storage of public dicussions.
Thanks. Yes. It looks like a code bug; that the edit code picks up the topic's timestamp rather than the post's timestamp.
This might have been fixed now by my spurios replacing of a 't' with a 'p'; otherwise it'll require thought.
The timeout is a day, or 86400 seconds, since the creation of the post.
@Vernon, it shouldn't have stopped you from editing that post so I'm not sure what is happening there.
'edit' and 'delete' are treated the same based on my reasoning that editing lets you remove all content, and a blank post is basically the same as a deleted post.
Wouldn't you neeed to use xvfb to run an X server remotely without displaying on a real console?
The package dqcache comes without any init.d script so it thus needs hand crafting.
1) Edit /etc/default/dqcache by adding "export" to every variable setting. For example:
# dqcache runs chrooted in the directory specified
# by the $ROOT environment variable
#
export ROOT="/var/lib/dqcache/root"# dqcache listens for incoming UDP packets and TCP connections
....
2) Create /etc/init.d/dqcache with the following:
#!/usr/bin/env /lib/init/init-d-script
### BEGIN INIT INFO
# Provides: atd
# Required-Start: $syslog $time $remote_fs
# Required-Stop: $syslog $time $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: DNS Cacher
# Description: Debian init script to start the dbcacher daemon
### END INIT INFO
DESC="DNS cacher daemon"
DAEMON=/usr/sbin/dqcache
PIDFILE=none
NAME=dqcache
START_ARGS=--background
export UID=$(id -u $NAME)
export GID=$(id -g $NAME)
3) Finalize with usual hands-on
# update-rc.d dqcache defaults
# update-rc.d dqcache enable
# service dqcache restartThe first point of call for that would be
$ dpkg -S bin/mate-system-log@GNUser: please note that R2 is an off-the-shelf router (TL-WR841N) and it offers only an http(s) admin panel rather than shell access.
@Devuman: with forwarding set up, you should use only
ssh <PC1user>@192.168.18.8That's the whole idea of forwarding. It makes R2 to channel tcp connections on its port 22 WAN side (ie 192.168.18.8:22) onto port 22 on PC1 (ie 192.168.1.101:22) without involving itself in the traffic.
The double-hop is used when you have ssh access to an intermediate host, to use that as a temporary forwarding channel.
That looks like a bug with that package, but you might be able to side-step that bug by temporarily making /usr/bin/update-alternatives be something else... something like
# mv /usr/bin/update-alternatives /usr/bin/update-alternatives.ORIG
# ln -s /bin/true /usr/bin/update-alternativesthen remove debian-edu-artwork
and then restore:
# mv /usr/bin/update-alternatives.ORIG /usr/bin/update-alternativesIf the ISP has port 22 closed outside of R1 then you probably need to contact them to open it. But that's only to get access to PC1 from the Internet.
The R1 virtual server set up you show on the screenshot makes it possible to access port 22 on PC1 from the Internet, provided that R2 is set up similarly, and that it has that IP address 192.168.18.8 mentioned on the screenshot as its WAN side IP address.
sftp access from LT2 to PC1 only requires the R2 set up (not the R1 set up), and PC1 would then be accessed using that same IP address.
An alternative could be to declare port 22 on PC1 to be a "virtual server" on R2, the TL-WR841N router.
https://www.tp-link.com/us/user-guides/ … ub-title-7
EDIT: Note that then LT2 would access PC1 by using the IP address of R2 on LAN1 rather than the PC1 IP address on LAN2.
Might you have forgotten to do
apt-get updateas well, so as to update your local package lists?
Please note the opening of the new well of knowledge: Freedom Hacks