You are not logged in.
I liked post #19 though; it was short and succinct, and its mere presence so elegantly violated its own sentiment.
Sorry. I lost interest there. Too many words. To paraphrase Ramsey: "What you can't say in just a few words, you should whistle.".
Why don't you find yourself a blog site somewhere, where it'd be good and natural to line up all those beautiful words. This forum is populated by mostly intelligent people with no need or desire to waste (more) time and thought on systemd.
To be clear, ICMP is a protocol and not a port; it's the Internet Control Message Protocol, whereby routers may exchange meta-data about IP level connectivity. There are several networking protocols to consider, both within the IP class (such as in particular TCP and UDP), and outside the IP class (in a range of varying obscurity).
As said before, there is no such thing as "invisible" on the Internet, short of not being connected at all. But there is a gray scale of "protection layers" of setting blockages for certain network traffic, depending on how you want your host to handle it. I'.e., like the rules you showed on top, which indeed tells the host to drop certain incoming ICMP packets, rather than deliver them to their normal handling (by the kernel). I think you'd do well in dropping IGMP as well, and then consider blocks for TCP and UDP messaging, which offer the majority of intentionally harmful networking.
libgnutls-deb0-28.so.28 ?
You can install eudev=220:3.2.2-devuan1 from experimental on Jessie, but you need to make sure to also install libudev1=220:3.2.2-devuan1, which is its companion (despite the name). The latter might be noted as a downgrade (relative jessie-backports), but that's nothing to worry about.
Thank you, and welcome. Good practice for another time, when you run into something harder. ![]()
Nothing to worry about. I'm pretty sure it's the right pathname.
But it just made me think about the Bellman.
You mention /usr/lib/mozilla/plugins/flash-mozilla.so twice already, so if I mention it once more, it'll sure be the right place ![]()
To be sure, each rule is on a single line. Refer to
man udevfor details.
I'm not too well versed in this, but I might be able to help.
Firstly, I think that your /etc/udev/rules.d/10-scanner.rules should have a single rule line. It should be read "if the vendor is 0x04f9 and the product is 0x0330, then make the /dev/whatever pathname have group scanner". All that needs to be on a single line.
What you have done is rather three independent statements: "if the vendor is 0x04f9, then eeh nothing", "if the product is 0x0330, then ehh nothing", "if whatever, then set /dev/whatever to have group scanner". That last one in particular is quite "destructive" (although there might be some kind of protection in udev for that kind of mistake).
But, when I look at the libsane rules (i.e., /lib/udev/rules.d/60-libsane.rules) it suggests that you should rather have the assignment
..., ENV{libsane_matched}="yes"as effect instead of setting access group. I think the deal is that the scanner dev's (for whatever [expletive] reason) have decided to use "acl" rather than unix file protection, and they also have programmed their rules to use a common, actual effect via the setting of the libsane_matched variable.
So, if making it a single line doesn't work, you might try replacing the GROUP assignment with that assignment.
EDIT: note the comma (",") between the terms; i.e., when you join your lines, you need to add "," comma between them.
Make a failed login attempt and see that btmp has grown ![]()
man last
man lastbIf I may suggest a couple of "improvements" within that scheme, to in particular simplify the picture for the helpee.
Firstly that you set up key based authentication for helpee, to ssh to you without password.
Secondly that you set up ~/.ssh/config for helpee with a short logical hostname to your host. In that you would also reverse forward to both ports 22 and 5900 in the single ssh link. E.g. like the following stanza
Host help
hostname ...
user ...
identityfile ...
remoteforward 7000 localhost:22
remoteforward 5901 localhost:5900Thirdly a script for the helpee to run the two things as one:
ssh help & x11vncWith the second forwarding, you, the helper, would only need to run vinagre against localhost:5901, or indeed xvnc4viewer against :1, and also have the ssh back link on localhost:7000.
... a bit sad to learn there was no magic ![]()
As for the reverse port forwarding, you might have overlooked the option of reverse-forwarding port 5900, which is the default port vnc uses for the :0 display. Though, with gitso working for you, there's no need to pursue this.
I suppose x11vnc accessed with xvnc4viewer via ssh is too old-fashioned?
If it's similar to my problem, https://dev1galaxy.org/viewtopic.php?pid=4135#p4135, then that xhci quirk setting might be a good thing for you as well.
There's also sshfs, which is more secure, but won't work right for audio/video (it plays on the server instead of the client.)
What does that mean? afaik sshfs is just a mounted (remote) file system for the client??
In fact as recent as last week, I used it with my mplayer on the client.
According to the hopefully relevant web page, here, you need to add a udev rule, which they provide a script for. That script however seems to concern a different idVendor:idProduct device from yours, and it would therefore not be immediately applicable.
However, since the script merely creates a new file to the udev configurations, /etc/udev/rules.d/73-beaglebone.rules, it is safe to try it, but first edit the script: replace the two occurrences of 0403 with your idVendor code, 1d6b, and the two occurrences of a6d0 with your idProduct code, 0104, before running the script (as root).
If it's helpful, it's all good, and if not, you can just remove the file.
Also, you should check permissions on /dev/bus/usb/001/00[56]
If udev doesn't recognize their vendor/product id, it'll just set up "generic" nodes, which probably are not accessible by a user.
Sometimes jmtpfs is sufficient.
This is a quick note that might help someone, although I haven't worked out the proper solution yet.
The deal is that recently my laptop stopped suspending properly. It suspends on closing the lid, but then immediately wakes up. It has Jessie installed since beta, then occasionally upgraded, and it has linux-image-4.9.0-0.bpo.2-amd64 from jessie-backports installed.
Eventually I worked out that apparently it is the xhci_pci module that gets a phantom signal from somewhere, and wakes up the system. I believe the module handles USB transport (esp. 3.0), and it is brought in when I plug in a USB stick.
So, my laptop is sleeping fine until I plug one in, and thereafter it keeps bouncing up, refusing to sleep, until I unload that module.
Perhaps there's some module option to avoid the misbehaviour. I'll add an edit here if I find something.
EDIT 1: I've realized this to be an age old problem, though ascribed to the xhci_hcd module rather.
EDIT 2: See https://bugzilla.kernel.org/show_bug.cgi?id=66171#c67 which suggests the fix of having
options xhci-hcd quirks=270336in an /etc/modprobe.d/ file, so as to make the module load with that parameter. I'll try that for a while...
Some people would use "code" blocks to make their posts readable.
Other people don't bother and don't get read.
The original poster does that by editing the "subject" line of the first post. You can try it out on this topic, if you think this answered your question.
a) any hardware loggging in /var/log/syslog or /var/log/kern.log ?
b) is Trash and file on the one and same partition ?
c) which actual program is it? ("mv" or "rm" or gui dnd)
E.g., by hearsay I think on an ext* file system, "rm" of a huge file will stall the system because it locks the directory while reclaiming the blocks, whereas an intra-partition "mv" however is instantaneous, being just some top level pointer juggling in the directory tables.
Yeah. By the looks of it, it's all set up perfectly fine, and renewal should have happened nicely and smoothly already last month. It didn't. As the "certbot" is something opaque in too many lines of python, it's become a matter of tracing it more tightly for the next time...