Re: OT: Strange behavior in Firefox -- google searches start by searching another URL / domain
rhkra...@gmail.com wrote: >This is definitely OT and further, I'm using an old version of Firefox (ESR >52.8.0 on Wheezy, which is still my daily driver), Not so much answering your original question, but more of a plea to you for *your* own safety... If you're going to use a web browser connected to the open internet, *please* upgrade and move forwards to something that has some security support. You're using a browser that was last updated three years ago on top of of an OS where security support ended *five* years ago. You are *asking* for trouble doing this. There have been many holes found and fixed in your browser that could allow for remote attackers to gain access to your system, and then multiple kernel security bugs that could easily give root privileges to an attacker who wanted them. By all means use old and unmaintained software if you wish - that's your right. But connecting old software to the internet is *dangerous*. You appear to be worried about a third-party website/domain potentially tracking your activity, but I think that should be the least of your concerns at this point. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: OT: Strange behavior in Firefox -- google searches start by searching another URL / domain
On Mon, Jun 07, 2021 at 06:08:39PM -0400, rhkra...@gmail.com wrote: > Thanks for the reply -- not quite, comments interspersed below: > > On Monday, June 07, 2021 04:38:24 PM Greg Wooledge wrote: > > On Mon, Jun 07, 2021 at 04:28:03PM -0400, rhkra...@gmail.com wrote: > > > time) when I go to do a google search, the little message down in the > > > lower left corner of the screen that typically gives messages like > > > (paraphrased): ~"waiting for google.com" or "loading data from > > > google.com" (with variations on the URL) sometimes starts with a > > > completely irrelevant URL (but one that I recognize and that concerns > > > me). > > > > Let's make sure we understand each other completely here. I believe > > what you are doing is: > > > > 1) Open firefox. It has a default or nearly-default configuration. > > > > 2) Go to www.google.com. > > > > 3) Search for something. Doesn't matter what. > > What I see is happening while the google search result page is "populating" > (or actually waiting for it to start populating), the first thing I see > (sometimes) is something like ~"waiting for buckslib.org" It might be firefox pre-fetching pages (or at least verifying they're actually reachable). Beyond that, I don't know.
Re: OT: Strange behavior in Firefox -- google searches start by searching another URL / domain
Thanks for the reply -- not quite, comments interspersed below: On Monday, June 07, 2021 04:38:24 PM Greg Wooledge wrote: > On Mon, Jun 07, 2021 at 04:28:03PM -0400, rhkra...@gmail.com wrote: > > time) when I go to do a google search, the little message down in the > > lower left corner of the screen that typically gives messages like > > (paraphrased): ~"waiting for google.com" or "loading data from > > google.com" (with variations on the URL) sometimes starts with a > > completely irrelevant URL (but one that I recognize and that concerns > > me). > > Let's make sure we understand each other completely here. I believe > what you are doing is: > > 1) Open firefox. It has a default or nearly-default configuration. > > 2) Go to www.google.com. > > 3) Search for something. Doesn't matter what. What I see is happening while the google search result page is "populating" (or actually waiting for it to start populating), the first thing I see (sometimes) is something like ~"waiting for buckslib.org" You don't have to go any further (i.e., to your step 4, the problem I see occurs before that). Aside: I am familiar with the behavior you describe below, the redirecting through www.google.com first. (For now, I haven't deleted the following.) > 4) Hover the mouse on one of the search results. A URL will be shown in >the lower left corner. > > 5) Actually click the search result. Instead of going to the page that >you saw in the corner prior to clicking, you are redirected through >www.google.com first. > > If this is what you mean, then yes, this is how Google works. It's not > specific to Firefox. > > If you replace step 4 with "Right-click on the URL and select Copy Link > Location, then paste the URL into a terminal", you'll see that the actual > URL is of the form > https://www.google.com/[stuff]&url=https%3A%2F%2F[realURL]. > > This is how Google knows which link you clicked on. > > Ostensibly, they do this so they can "score" their search results and > promote the ones that people click, and demote the ones they don't. > > Whatever else they may use this information for... is not public knowledge, > but we can speculate. > > So, you may be asking, "Hey, if the real URL that I'm going to visit is > www.google.com/something, why is it showing me www.debian.org in the > corner of the page?" Javascript. The answer is Javascript. It allows > page creators to lie to end users in all kinds of ways.
Re: OT: Strange behavior in Firefox -- google searches start by searching another URL / domain
On Mon, Jun 07, 2021 at 04:28:03PM -0400, rhkra...@gmail.com wrote: > time) when I go to do a google search, the little message down in the lower > left corner of the screen that typically gives messages like (paraphrased): > ~"waiting for google.com" or "loading data from google.com" (with variations > on the URL) sometimes starts with a completely irrelevant URL (but one that I > recognize and that concerns me). Let's make sure we understand each other completely here. I believe what you are doing is: 1) Open firefox. It has a default or nearly-default configuration. 2) Go to www.google.com. 3) Search for something. Doesn't matter what. 4) Hover the mouse on one of the search results. A URL will be shown in the lower left corner. 5) Actually click the search result. Instead of going to the page that you saw in the corner prior to clicking, you are redirected through www.google.com first. If this is what you mean, then yes, this is how Google works. It's not specific to Firefox. If you replace step 4 with "Right-click on the URL and select Copy Link Location, then paste the URL into a terminal", you'll see that the actual URL is of the form https://www.google.com/[stuff]&url=https%3A%2F%2F[realURL]. This is how Google knows which link you clicked on. Ostensibly, they do this so they can "score" their search results and promote the ones that people click, and demote the ones they don't. Whatever else they may use this information for... is not public knowledge, but we can speculate. So, you may be asking, "Hey, if the real URL that I'm going to visit is www.google.com/something, why is it showing me www.debian.org in the corner of the page?" Javascript. The answer is Javascript. It allows page creators to lie to end users in all kinds of ways.
OT: Strange behavior in Firefox -- google searches start by searching another URL / domain
This is definitely OT and further, I'm using an old version of Firefox (ESR 52.8.0 on Wheezy, which is still my daily driver), but I want to describe the behavior and see if anybody has seen anything similar, has an explanation, or has a fix. The behavior is this: at least sometimes (I can't confirm that it happens every time) when I go to do a google search, the little message down in the lower left corner of the screen that typically gives messages like (paraphrased): ~"waiting for google.com" or "loading data from google.com" (with variations on the URL) sometimes starts with a completely irrelevant URL (but one that I recognize and that concerns me). The URL is buckslib.org, which is the URL of a public library (in the US) of which I am a member. My concerns include the following: * is buckslib.org somehow tracking what I do on google? * even if not, this seems to be slowing down my search results I have experimented with disabling cookies from both https://buckslib.org and the http:// variation, but that doesn't seem to have an effect. Any ideas how this could be happening or how to stop it? (I do plan to write to the administrator at buckslib.org, but I thought I'd try to do some investigation first (into how this might happen.) All ideas welcome, including search terms which might be useful to search for more information on google or such. Thanks!
Re: A Grub Boot Question about initrd
On Sun 06 Jun 2021 at 14:14:38 (+0300), Andrei POPESCU wrote: > On Sb, 05 iun 21, 12:46:13, Martin McCormick wrote: > > > > One should be able to write a program to get the > > appropriate UUID's out of fstab on the working system > > and translate them in to corresponding UUID's for the system on > > the operating table. > > Alternatively you might want to consider using standardized labels on > all your system, e.g. 'rootfs' is always the root partition, etc. When you plug in another potential system disk, you now have two partitions with LABEL=rootfs, which I would find even more confusing. But then, I'm someone who believes in tying the label physically written on the disk (eg magic marker) with the partition LABELs on that disk. > If all your devices have GPT partition tables you could also use > partition labels instead, as they will survive a re-format of the file > system. Since their invention, I personally use PARTLABELs to tie together the LABELs and the partitions' intended use. They can be quite long, but for me, something like Toto-Home suffices, where toto is the disk and /home is the use. Again personally, I avoid using 16-byte UUIDs altogether, so any grub-mkconfig is followed by my postprocessing to convert them all to LABELs, thereby making grub.cfg comprehensible for humans. (Wouldn't GRUB_ENABLE_LABEL be nice.) The only UUIDs in my fstab are the FAT ones (which I set manually on USB/SD devices if I'm doing the formatting) and any NTFS ones I'm forced to use. And the only devices are /dev/sr0 and /dev/mmcblk0p1 as appropriate. Cheers, David.
Re: ISC-DHCP server number of active leases
Bonno Bloksma wrote: > Hi, > > I am running multiple isc-dhcp servers on Debian Linux. > I have several sites with multiple networks and I use the isc-dhcp-server to > hand out ip numbers in the various network segments. In most of the networks > I have more then enough free ip numbers all the time. > However, in some networks I KNOW I regularly hand out far more then 50% of > the assigned ip numbers and I have set the default and max-lease-time low > enough to free up ip numbers asap. So far so good, I have had no problems > this year but... we are growing and people have more mobile devices so I want > to know HOW CLOSE I am to running out of free dhcp leases. > > Which tool can help me getting insight in the number of active dhcp leases. > It would be really great if it gave insight including a history of when how > many ip numbers were in use at any given time segment. > That would show me whether I am getting close to saturation at any given > moment in the day. > apt install dhcpd-pools -dsr-
ISC-DHCP server number of active leases
Hi, I am running multiple isc-dhcp servers on Debian Linux. I have several sites with multiple networks and I use the isc-dhcp-server to hand out ip numbers in the various network segments. In most of the networks I have more then enough free ip numbers all the time. However, in some networks I KNOW I regularly hand out far more then 50% of the assigned ip numbers and I have set the default and max-lease-time low enough to free up ip numbers asap. So far so good, I have had no problems this year but... we are growing and people have more mobile devices so I want to know HOW CLOSE I am to running out of free dhcp leases. Which tool can help me getting insight in the number of active dhcp leases. It would be really great if it gave insight including a history of when how many ip numbers were in use at any given time segment. That would show me whether I am getting close to saturation at any given moment in the day. Bonno Bloksma
Re: A Grub Boot Question about initrd
Felix Miata writes: > This is a big lurking booby trap that could have been the problem both > last time > and this time. It's one of the reasons why installation systems and Grub > switched > from using device names to using UUIDs: inconsistent and/or unpredicable > device > enumeration. > > Is this a PC with both PATA and SATA controllers? These old PCs can > compound the > issue. > > Different kernel, disk controller, USB controller and BIOS combinations > can cause > e.g. an SATA or PATA disk sda to become sde, or sdb become sda, IOW, > device names > that don't persist. UUIDs are supposed to prevent inconsistent device > names from > being a problem, but in a rescue environment, it can muddy the waters, or > backfire. Yes on all counts. These are old PC's that use IDE controllers. The IDE cables end in the normal 34-conductor header with one pin missing on one side that plugs directly in to the drive. In this case, the connector plugs in to a SATA-to-IDE converter with a female SATA connector. I believe you have hit the nail on the head because I know for a fact that the devices change names. On the working system, the boot device we would normally think of as /dev/sda is /dev/sdc and 5 minutes from now might be /dev/sdq depending on what drives were plugged in to usb ports when the system booted. Just yesterday, I mounted /dev/sdd, thinking it was the now infamous unbootable drive and immediately realized that I was looking at the boot drive that starts the good system. I had plugged a thumb drive in to a usb port some time earlier and then rebooted the system while failing to remove the thumb drive as it wasn't even being used right then. Let's see. $ dd if=/dev/sdd of=/dev/sde What could possibly go wrong? Just kidding this time but that's what we are dealing with. That possibly lethal command can work but only under the right circumstances so if one forgot to recreate the world one was working with, it's tuition in the school of hard knocks. I haven't yet totally given up and done anything else rash so it's still full steam ahead. This is one of those situations where if a person has the time, this can be a teachable moment. I've got several thumb drives that I mount based on their UUID and that method of doing things is your friend if you understand how to use it. If not, what one ends up with is total chaos. Felix's message hasn't saved the day yet but it confirms my hunch that the UUID's have been at the heart of this problem all along because there is simply no other logical reason why one can not transplant the same boot logic from one system to the other when they are functional copies of each other. The trick will be to replace every UUID personalization which is doable. Whether it is practical still remains to be seen. To briefly reference an earlier message, I checked the good system to see what rsnapshot did over night and /boot is now committed to a series of little capacitors which is how SSD's remember things. From fstab: # /etc/fstab: static file system information. UUID="49c4eda8-3bcc-445e-841b-513b07d560fe" /var/cache/rsnapshot ext4 relatime,rw,user,noauto 0 0 If that drive wasn't always plugged in, the boot drive would have a different device number than /dev/sdc1 which is also mounted by UUID. That drive also plugs directly in to a usb slot and not any extender to hopefully insure that it is more likely to be present. I will uncompress the initrd files and see how hard it will be to find the UUID and change it to what it should be on the problem target system. Again, thanks to all. Martin WB5AGZ
Re: Trunk-bond-vlan-bridge on KVM and LXC host Stretch x Buster
Thanks for your replay, Reco. Yes, in Stretch networking works well both - with and/or without directive "auto". In contrast Buster with: auto bond0.20 iface bond0.20 inet manual auto bond0.21 iface bond0.21 inet manual gateway is unreachable by ping. So I don't know why yet. Ales From: Reco Date: Fri, 4 Jun 2021 16:51:05 +0300 It's just a guess, but you have "auto" for "bond0": auto bond0 iface bond0 inet manual But what you do not have is "auto" for VLAN interfaces you build on top of bond0: iface bond0.20 inet manual iface bond0.21 inet manual
Re: Complaints from mousepad.
I deleted the OP's last message from this thread, and then soon afterward came up with something I should have said. So, there's no quoted context here. Sorry. The OP is basically claiming that "telnet from Osa" and "ssh from another machine" both *work*, but give different warning messages, and now they want to know why the warnings are different. (Because they have too much free time or something.) My first guess is there's a difference between the PAM configurations for sshd and telnetd. One might try comparing /etc/pam.d/sshd to whatever the analogous file is for telnetd. Or, it could be something that's hard-wired into sshd itself, perhaps configured in the /etc/ssh/sshd_config file. The interactions between various login services and the XDG Universe (dbus and so on) is still somewhat opaque to me, but if the OP really wants to know this stuff, that's the direction they need to look.
Re: Complaints from mousepad.
Hello Peter,
pe...@easthope.ca writes:
[...]
> 0) mousepad --display=:0 /home/me/a & ;;
[...]
> (mousepad:8747): dconf-WARNING **: 06:30:53.773: failed to commit
> changes to dco nf: Cannot autolaunch D-Bus without X11 $DISPLAY
>
> How should the shell function or mousepad notify dconf that the
> display is :0?
Have you tried setting the DISPLAY environment variable like the warning
mentions? That's the standard mechanism for X11 applications to know
which server to connect to.
Alternatively you might want to either start a D-Bus session explicitly
(using e.g. dbus-run-session) or connect to an existing D-Bus session
bus by extracting DBUS_SESSION_BUS_ADDRESS from the environment that has
a running D-Bus session and setting it in the environment where you want
to run mousepad. Which solution is better depends on which applications
you want to be able to talk to each other.
For example you could place this in your .xsession:
echo export DBUS_SESSION_BUS_ADDRESS="${DBUS_SESSION_BUS_ADDRESS}" > ~/.dbusaddr
And then in your met() function:
( source ~/.dbusaddr && exec mousepad --display=:0 /home/me/a ) &
The subshell ensures only mousepad sees
DBUS_SESSION_BUS_ADDRESS. Otherwise you'd get different behaviour from
various applications based on exactly when you started your editor. If
you want all applications to access this session bus, place "source
~/.dbusaddr" somewhere else. Just be careful where you place it; you
might end up overriding the address of the new session bus when you
start your X11 session.
Sascha
signature.asc
Description: PGP signature
