Re: SOLVED - Re: Deb10 installer can't install grub
On Wed, Mar 03, 2021 at 10:28:34AM -0500, Marc Auslander wrote: > One potential gotcha. When you boot from an mdadm file system containing > /boot/grub, grub will not write to the file system. In particular, it will > not update grub/grubenv even if you have a save_env line in grub.cfg. So if > you use grub-reboot to specify an alternate line in grub.cfg, you need to > reset grubenv afterwards. I do this in a root @reboot cron job. > > If you don't know what I'm talking about, you probably don't need to worry > about this. I don't *know* know what you're talking about, but I think I get the gist of it. I'm not doing anything fancy enough to have to deal with the details of grubenv and grub-reboot, but your initial comment about grub refusing to write to a mdadm filesystem is consistent with what I was seeing, and it's nice to have confirmation that it actually does work that way. -- Dave Sherohman
SOLVED - Re: Deb10 installer can't install grub
So, after my last message, I ran across a general mdadm setup guide at https://raid.wiki.kernel.org/index.php/Setting_up_a_(new)_system and, in the "booting" section of that document, it said to add GRUB_CMDLINE_LINUX="domdadm" to /etc/default/grub. Didn't have that, so I added it, did the checks mentioned in the document, and reinstalled grub to both EFI partitions. Still didn't work. Then I found https://linoxide.com/linux-how-to/grub-rescue-commands/ and was able to start the installed kernel with the command sequence: set root=(md/1) linux (md/1)/vmlinuz root=/dev/md1 initrd (md/1)/boot/initrd.img-4.19.0-14-amd64 insmod normal boot This still ultimately died with an error saying the EFI partition had an "Invalid FSINFO signature". Searches on that phrase mostly seemed to talk about secure boot problems, so I double-checked the bios options and secure boot was off, so that wasn't it. So I went back to the linoxide.com document and went through all the steps that I hadn't already done manually: Running os-prober and update-grub. Then grub-install to the EFI partitions again, reboot, and... success! Based on this, I'm guessing that the original problem was that the installer forgot to include mdadm support in its grub options, even though it was configured with an mdadm boot device. And then I missed a couple steps after adding mdadm support, so it didn't all get installed to the EFI partitions correctly. -- Dave Sherohman
Re: Deb10 installer can't install grub
General update on my situation: Just before knocking off for the day, I tried telling the installer to finish up without installing a boot loader, then used the netinst USB stick as a rescue disk to boot my installed system. From there, I was able to use the regular grub-install program (instead of the install environment's grub-installer script). grub-install ran with no errors and I now have grub in the (separate, non-RAIDed) EFI partitions of both nvme drives... but it's still not directly bootable. Trying to boot directly from nvme drops me into a grub command line. Thinking that this may be an initrd or similar issue, I tried reinstalling the kernel image and grub-efi-amd64 packages, so that their postinst scripts would run and rebuild initrd and reinstall grub to the drives, but that had no effect. Still just getting the grub shell when I boot from nvme. Any tips on making use of the grub shell to make further progress, such as getting the system to boot in non-rescue mode (i.e., not chrooted from the installer)? The help information available in the grub shell itself isn't terribly useful because it scrolls off the screen with no (obvious) pager or scrollback buffer. Alternately, suggestions for things I can try in the chroot environment would also be good, since that's considerably less restrictive than the installer environment I was trying to work within yesterday. I guess the most obvious explanation for the current grub issues is that grub isn't smart enough to boot an mdadm filesystem directly and I need to repartition with a non-RAID /boot, but I don't consider that a desirable solution, since it would then leave me with no /boot if the device holding that partition dies. (No new text below this point, just my original post for context.) On Tue, Mar 02, 2021 at 05:57:37AM -0600, Dave Sherohman wrote: > I've got a new server and am currently fighting with the Debian 10 > installer (build 20190702) in my attempts to get it up and running. > After much wailing and gnashing of teeth, I managed to get it to stop > complaining about being unble to mount /boot/efi and complete the > "Partition disks" step successfully, but now I'm completely stuck on the > "Install GRUB" step. > > The GUI installer shows the error: > > Unable to install GRUB in dummy > Executing 'grub-install dummy' failed. > > Checking the syslog output on virtual console 4 shows a bunch of > os-prober activity (as expected), then finally: > > Installing for x64_64-efi platform. > grub-install: error: failed to get canonical path of `/dev/nvme0n1p1`. > error: Running 'grub-install --force "dummy"' failed. > > I assume that the "canonical path" it's looking for is a /dev/sda-type > device name, but I have no idea how to assign one of those to an nvme > drive. (And I thought that kind of name was supposed to have been > banished in favor of "predictable" names by now anyhow.) > > Several of the old-style names are already in use; the installer is > showing sda for the USB stick that the installation was booted from and > sdb-sdi for eight large disks, but the operating system is to boot and > run from the drives /dev/nvme0n1 and /dev/nvme1n1. > > What do I need to do to get this working? > > Also, would that solution also work for md devices as well as for nvme > devices? I had previously tried putting UEFI onto a RAID1 mirror > between the two nvme drives, but got a similar error from grub about not > being able to find the canonical path of /dev/md1. > > -- > Dave Sherohman > -- Dave Sherohman
Re: Deb10 installer can't install grub
On Tue, Mar 02, 2021 at 09:26:21AM -0500, The Wanderer wrote: > I didn't parse what he wrote that way. He said: > > >>>> You'll want to create the following partitions on each, > >>>> identically: > >>>> > >>>> 1 efi - type efi > >>>> 2 boot (or boot/root) - type MDADM volume > >>>> 3 root, if using separate boot - type MDADM volume > >>>> 4 swap - type MDADM volume > >>>> > >>>> Then you go to the mdadm setup and create MDADM RAID1 devices > >>>> out of each pair of boot, root and swap. > > Note that he specified to RAID the three listed MDADM partitions, but > did not mention the same for the EFI partition. Ah, right. When he mentioned RAIDing the boot, I took that to mean the EFI partitions. Forgot that he as using a separate /boot. So I took a look at the grub-installer script, and guess what I found as a comment just before the `ls` that kills it? --- # XXX cjwatson 2019-03-25: This is all far too complicated and fragile, and # should be replaced with in-target or similar. # Ensure proc is mounted in all the $chroot calls; # needed for RAID+LVM for example initial_proc_contents="$(ls $ROOT/proc)" --- "Far too complicated and fragile", indeed! -- Dave Sherohman
Re: Deb10 installer can't install grub
On Tue, Mar 02, 2021 at 09:09:52AM -0500, The Wanderer wrote: > On 2021-03-02 at 09:01, Dave Sherohman wrote: > > > On Tue, Mar 02, 2021 at 07:54:01AM -0500, Dan Ritter wrote: > > >> Then you go to the mdadm setup and create MDADM RAID1 devices > >> out of each pair of boot, root and swap. > > > > RAID Device #1 is 1.9 TB, ext4fs, and set to mount on / > > RAID Device #2 is 2.0 GB, ESP, and bootable > > So the EFI partitions themselves are also RAIDed? I wouldn't have > expected that to work. That was my expectation as well, but Dan said it should work, so I went with it. Of course, I've also tried it with then not RAIDed and the results are identical, aside from the "canonoical path" error message in syslog changing from /dev/md2 to /dev/nvme0n1p1. > Is grub-installer specific to the Debian installer environment? I don't > find it at a glance in my installed system, or with 'apt-file search'; I > do find grub-install, which is a binary (where the error you quote seems > to indicate a script), and is what I seem to recall having used for the > manual installation of GRUB that finally got my current machine working > with a RAIDed boot-drive pair all those years ago. (Albeit not with EFI > boot partitioning, so that may not be directly comparable.) Yes, it seems to be unique to the installer environment. I made that same trip in reverse, first trying to run grub-install, and then having to go looking when that didn't exist. > If grub-installer is a script and is the correct thing to use, the first > thing I'd be inclined to do in your place is to examine that script and > see what it's trying to do at the point of the error, so that I can > figure out what it expects as input and how I can potentially try to > provide that. Good thought. It's a shell script, so I'll see if I can make sense of what it's doing in [filesystem]/proc. -- Dave Sherohman
Re: Deb10 installer can't install grub
On Tue, Mar 02, 2021 at 07:54:01AM -0500, Dan Ritter wrote: > In the installer, you want expert mode. Does the disk > partitioner recognize both nvme0n1 and nvme1n1 ? Yes. The list of disks shown in the partitioner is currently: RAID device #1 RAID device #2 /dev/nvme0n1 /dev/nvme1n1 SCSI2 (0,0,0) (sda) - the USB stick I booted from SCSI1 (0,0,0) (sdb) - the first storage drive ... the other seven storage drives ... > You'll want to create the following partitions on each, > identically: > > 1 efi - type efi > 2 boot (or boot/root) - type MDADM volume > 3 root, if using separate boot - type MDADM volume > 4 swap - type MDADM volume Partitioning is identical on both nvme drives, consisting of: 1.0 MB free space 2.0 GB ESP (bootable) 8.0 GB swap 1.9 TB RAID physical device 331.8 kB free space > Then you go to the mdadm setup and create MDADM RAID1 devices > out of each pair of boot, root and swap. RAID Device #1 is 1.9 TB, ext4fs, and set to mount on / RAID Device #2 is 2.0 GB, ESP, and bootable > After install to those RAID1 devices, grub will want to install. > Do that to the boot sector of /dev/nvme0n1, and then again to > the boot sector of /dev/nvme1n1. ...and this is where it dies. I'm now in the text-mode "expert install", and there is no option to manually specify a partition to install GRUB on, only a yes/no "Force GRUB installation to the EFI removable media path?" prompt. Regardless of which answer I choose, I get "Unable to install GRUB in dummy" and syslog records "failed to get canonical path of /dev/md2". I also tried dropping to a shell and manually running `grub-installer /dev/nvme0n1` and got the error "ls: /dev/nvme0n1/proc: Not a directory" Manually running grub-installer for /dev/md2 and /dev/nvme1n1 (unsurprisingly) produced similar results. -- Dave Sherohman
Deb10 installer can't install grub
I've got a new server and am currently fighting with the Debian 10 installer (build 20190702) in my attempts to get it up and running. After much wailing and gnashing of teeth, I managed to get it to stop complaining about being unble to mount /boot/efi and complete the "Partition disks" step successfully, but now I'm completely stuck on the "Install GRUB" step. The GUI installer shows the error: Unable to install GRUB in dummy Executing 'grub-install dummy' failed. Checking the syslog output on virtual console 4 shows a bunch of os-prober activity (as expected), then finally: Installing for x64_64-efi platform. grub-install: error: failed to get canonical path of `/dev/nvme0n1p1`. error: Running 'grub-install --force "dummy"' failed. I assume that the "canonical path" it's looking for is a /dev/sda-type device name, but I have no idea how to assign one of those to an nvme drive. (And I thought that kind of name was supposed to have been banished in favor of "predictable" names by now anyhow.) Several of the old-style names are already in use; the installer is showing sda for the USB stick that the installation was booted from and sdb-sdi for eight large disks, but the operating system is to boot and run from the drives /dev/nvme0n1 and /dev/nvme1n1. What do I need to do to get this working? Also, would that solution also work for md devices as well as for nvme devices? I had previously tried putting UEFI onto a RAID1 mirror between the two nvme drives, but got a similar error from grub about not being able to find the canonical path of /dev/md1. -- Dave Sherohman
Re: Can nginx "events" block be configured in an include file?
On Tue, Nov 03, 2020 at 10:06:30AM -0600, David Wright wrote: > On Tue 03 Nov 2020 at 08:03:24 (-0600), Dave Sherohman wrote: > > Another (off-list) reply suggested using a script to edit nginx.conf > > rather than doing it by hand, which looks like the best solution for my > > specific case. > > I obviously haven't seen that suggestion, but why write a script > yourself when software exists to do that already. Because my deployment script already exists and does several things other than editing nginx.conf, and I prefer being able to deploy with one command instead of two. > Patch, of course, has the same pedigree as Perl, both being creations > of Larry Wall. I'm passigly familiar with `patch`, but wasn't aware that Larry was the original author. Thanks for that tidbit! -- Dave Sherohman
Re: Can nginx "events" block be configured in an include file?
On Tue, Nov 03, 2020 at 07:57:40AM -0500, Greg Wooledge wrote: > On Tue, Nov 03, 2020 at 03:35:58AM -0600, Dave Sherohman wrote: > > tl;dr: I need to increase worker_connections on my nginx servers, but > > don't want to edit the debian-provided nginx.conf due to that causing > > future upgrade hassles. Is this possible? > No. Ah, well. That's what I expected, but thanks for confirming it. Another (off-list) reply suggested using a script to edit nginx.conf rather than doing it by hand, which looks like the best solution for my specific case. My site-specific config files are generated from templates using a Perl deployment script, and I also have hooks there which I can use to edit nginx.conf without needing to generate the whole thing from a template, and that will also handle nginx config changes coming from debian by re-patching the config the next time we deploy. -- Dave Sherohman
Can nginx "events" block be configured in an include file?
tl;dr: I need to increase worker_connections on my nginx servers, but
don't want to edit the debian-provided nginx.conf due to that causing
future upgrade hassles. Is this possible?
Long version:
I've got a couple servers running a somewhat convoluted web app
deployment, with nginx at the front end. Every so often, one of the
nginx instances will lock up and start logging "768 worker_connections
are not enough" messages on every request.
After some searches and double-checking that there aren't any loops in
my nginx config, I've come to the conclusion that 768 is an absurdly low
default for production servers - one source said that "over 9000" is
appropriate for most sites that see significant traffic.
So I'm thinking I should probably raise it. However, when I tried
raising it from conf.d, nginx failed to start, with the error
[emerg] 25402#25402: "events" directive is not allowed here in
/etc/nginx/conf.d/mysite.conf:1
conf.d/mysite.conf contains only:
---
events {
worker_connections 10240;
# multi_accept on;
}
---
I also tried moving that config file to modules-enabled/ and it at least
gave me a different error message:
[emerg] 14914#14914: "events" directive is duplicate in /etc/nginx/nginx.conf:6
so it apparently accepted my events block, then choked on the default
one.
Is there any way to accomplish this using only new files of my own
creation, while leaving all debian-provided config files in a pristine
state?
I know I could change it directly in /etc/nginx/nginx.conf, but
a) That would potentially generate conflicts with new debian-provided
versions of nginx.conf whenever the package is upgraded
b) My site-specific config files are generated from templates, meaning
that I'd then need to keep the template in sync with any debian-
provided changes, or go outside the existing system and have to
remember to manually tweak nginx.conf every time I make a new server
or upgrade an existing one
and I would greatly prefer a one-time change which doesn't lead to
either of those ongoing maintenance concerns.
--
Dave Sherohman
Re: Buster without systemd?
On Mon, Mar 23, 2020 at 09:59:25AM +0100, Renato Gallo wrote: > Rly, systemd is, between things, a way to be sure when and after what > something starts isn't it ? I expect that there would be much, much less resistance to systemd if that were all that it does. However, it has evolved to take over a number of other functions aside from managing the order that services are started, which makes many people uncomfortable with it. -- Dave Sherohman
Video display via Thunderbolt docking station (Lenovo/Lenovo)
ration Device 1fb9 (rev a1) 01:00.1 Audio device: NVIDIA Corporation Device 10fa (rev a1) 02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981 04:00.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] (rev 06) 05:00.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] (rev 06) 05:01.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] (rev 06) 05:02.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] (rev 06) 05:04.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] (rev 06) 06:00.0 System peripheral: Intel Corporation JHL7540 Thunderbolt 3 NHI [Titan Ridge 4C 2018] (rev 06) 07:00.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge DD 2018] (rev 06) 08:02.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge DD 2018] (rev 06) 08:04.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge DD 2018] (rev 06) 09:00.0 USB controller: Intel Corporation JHL7540 Thunderbolt 3 USB Controller [Titan Ridge DD 2018] (rev 06) 52:00.0 Network controller: Intel Corporation Device 2723 (rev 1a) 53:00.0 SD Host controller: Genesys Logic, Inc Device 9755 -- Dave Sherohman
Re: I support the founder of FreeSoftware
On Thu, Sep 19, 2019 at 12:19:50PM +0300, aprekates wrote: > ps: for the members of the debian community not fully aware of > attack i'd recommend as entry readings: > > https://itsfoss.com/richard-stallman-controversy/ > > https://medium.com/@selamie/remove-richard-stallman-fec6ec210794 > > http://www.tuxmachines.org/node/128122 Also, https://www.theregister.co.uk/2019/09/17/richard_stallman_final_interview/ It's nominally an interview with Stallman about his visit to Microsoft, which was conducted just before the original attack on him, but it has a lengthy preamble describing the situation (from a decidedly anti-Stallman viewpoint, with a heavy emphasis on "the only reason we didn't grill Stallman on how evil his is is because we didn't know yet"). -- Dave Sherohman
Adding buster endpoint to stretch icinga2 server
I've been using icinga2 for monitoring several stretch systems for quite a while, and now I'm starting to add buster machines to my herd, but haven't been able to work out how to (easily) get the old server to recognize the existence of new clients. Going through the process of running the wizard on the new client, PKI handshaking, and so on all went off without a hitch. However, after getting everything set up on the client and restarting icinga on the client, I'm stuck. Previously, I have made the master aware of the new client endpoint by running # icinga2 node list # icinga2 node update-config And, yes, "DEPRECATED! Please read the Changelog.", but the Changelog doesn't say anything that's actually useful in terms of "instead of using `icinga2 node foo`, you should use this other command". So now they've apparently stopped working with buster clients (they don't show up in the list of nodes) and the checks I've configured on the master throw errors when I run `icinga2 daemon -C` because they refer to an Endpoint which, according to the master, doesn't exist. What is the preferred/"correct" way of making the master aware of the new Endpoint? I can see by inspecting the existing files that I could do this manually by going into the endpoints, zones, and hosts directories and creating files for the new client in each of those three directories, but, aside from being a PITA, that seems sufficiently error-prone (typos, etc.) that it doesn't seem likely to be the preferred method. -- Dave Sherohman
Re: sending mail via a script
On Tue, Jul 16, 2019 at 10:39:57PM +0100, mick crane wrote: > well when I became aware of all this stuff, I thought this is great, > everybody can connect and do what they like, if of course following > protocols. > But you can't do that can you ? you have to connect through a service > provider. Certain ISPs (primarily those focusing on home customers, and especially those providing dynamic IP addresses) will block outbound connections to port 25 (smtp) by their clients. If your connection comes from such a provider, then, yes, you do have to pass your mail through their mail server, because their firewalls will prevent you from directly connecting to any other mail servers. But if you're not in such a situation, then you absolutely can run your own mail server, although there are hoops you need to jump through to avoid being mistaken for a spammer. Having a static IP in a non-blacklisted subnet and properly-configured DNS pointing back to that IP address are, in my experience, the primary factors. I don't think I've ever needed to do more than that for my own personal mail server, which I've been running since the summer of 2000, and it's been connected on at least 4-5 different ISPs over that time, including both residential and commercial providers. If you want to send mail claiming to originate from other servers, then *that's* where it gets tricky and cumbersome, because you need to properly handle SPF and DKIM restrictions, which you may not have any direct control over. I occasionally have to deal with this at work, and it's never a pleasant experience. -- Dave Sherohman
Re: buster changes vim mouse behavior again...
On Mon, Jul 08, 2019 at 08:50:56PM +0300, Andrei POPESCU wrote: > On Lu, 08 iul 19, 08:48:15, Dave Sherohman wrote: > > Today I did a test install of buster, however, and found a new problem: > > It seems that buster's vim detects the middle-click and "helpfully" goes > > immediately into insert mode, meaning that ":set paste" and "O" are > > entered as part of the file contents rather than being processed as > > commands. > If you do figure out how it's supposed to work please do post on list. My stackexchange question was identified as a duplicate of https://vi.stackexchange.com/questions/18001/why-cant-i-paste-commands-into-vi which gave me enough information to track down ":set t_BE=" (in addition to the existing ":set mouse=") as a solution to my problem. A full description of the behavior can be found at https://vimhelp.org/term.txt.html if you do a search in the page for "xterm-bracketed-paste". ":set termcap" shows that stretch's vim doesn't support the t_BE setting, which is why it doesn't need to be cleared there. -- Dave Sherohman
buster changes vim mouse behavior again...
Last time around, stretch changed mouse behavior in vim by setting "mouse=a" by default. To deal with this, my checklist for stretch updates/installs includes --- vi /etc/vim/vimrc.local :set mouse= :set paste O " Don't silently ignore these settings in favor of those in default.vim let g:skip_defaults_vim = 1 " Middle-mouse should paste from X clipboard, NOT vim clipboard! set mouse= --- I copy (mouse highlight)/paste (middle-click) the first line into my terminal, manually type the first `:set mouse=`, and then copy/paste the rest of it. Works great in stretch. Today I did a test install of buster, however, and found a new problem: It seems that buster's vim detects the middle-click and "helpfully" goes immediately into insert mode, meaning that ":set paste" and "O" are entered as part of the file contents rather than being processed as commands. I suppose that's handy for simple cases like this, where I ultimately am just inserting text into a file, but I also frequently want to run the same command in vim on a couple dozen different files, so it's really handy to be able to paste commands into the vim window and have the command executed instead of being inserted into the file's content. So how do I bring back the old behavior? In addition to ":set mouse=", I've also tried ":set ttymouse=" and ":set sessionoptions-=terminal", but these had no effect on this behavior. Crossposting notice: I have also posted this question on the vi/vim stack exchange site at https://vi.stackexchange.com/questions/20548/allow-pasting-into-all-modes-not-just-insert -- Dave Sherohman
Re: No jigdo images yet?
On Mon, Jul 08, 2019 at 11:08:15AM +0200, Thomas Schmitt wrote: > it is an old bug of jigdo-lite that it cannot download .jigdo and > .template files via https: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865864 > > So manually download the .template file too and then run jigdo-lite again. > There is hope that the new system can install jigdo-lite without that bug. > It might be interesting to learn whether this is really true. Thanks. Manually downloading the .template seems to have done the trick. I also tried manually applying the patch from that bug report, but it doesn't seem to have helped, but we can still hope that the version that made it into the 0.7.3-5 release actually works. -- Dave Sherohman
Re: will Release come back for testing/updates at security.debian.org?
On Mon, Jul 08, 2019 at 11:54:01AM +0300, Andrei POPESCU wrote: > On Lu, 08 iul 19, 03:10:53, Dave Sherohman wrote: > > On Sun, Jul 07, 2019 at 03:22:40PM +0200, Salvatore Bonaccorso wrote: > > > That will be actually a permanent change, see > > > https://lists.debian.org/debian-security/2019/06/msg00015.html . The > > > intention was actually do to it already in earlier cycle, but was not > > > possible (cf. > > > https://lists.debian.org/debian-security/2015/12/msg00015.html). > > > > What was the intended method for people upgrading from pre-buster > > versions to find out about this change? Just wait for them to try to do > > an update, get an error message, and hope that they ask on the mailing > > list instead of just commenting out the security updates line? > > Testing users are supposed to be able to handle such breakage. > > When bullseye becomes stable this will most likely be documented in the > Release Notes. Ah, ok, thanks. I guess I wasn't following the thread properly and I was thinking this change was happening in buster, not bullseye. My mistake; sorry about that. -- Dave Sherohman
No jigdo images yet?
Back from the weekend, and now I'm trying to do a jigdo download of the new buster install image, but having no luck. Are the jigdo files not up yet (although they seem to be there when I access them with other tools instead of jigdo-lite), or are the instructions on debian.org wrong, or am I somehow misunderstanding them? Transcript of what I've tried, along with a couple ### notes ### about where I got my information and some alternatives I tried: --- cut here --- $ sudo apt-get install jigdo-file Reading package lists... Done Building dependency tree Reading state information... Done jigdo-file is already the newest version (0.7.3-4+b1). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. $ jigdo-lite https://cdimage.debian.org/debian-cd/current/amd64/jigdo-cd/debian-10.0.0-amd64-netinst.jigdo Jigsaw Download "lite" Copyright (C) 2001-2005 | jigdo@ Richard Atterer | atterer.net Loading settings from `/home/council/.jigdo-lite' File `https://cdimage.debian.org/debian-cd/current/amd64/jigdo-cd/debian-10.0.0-amd64-netinst.jigdo' does not exist! $ wget https://cdimage.debian.org/debian-cd/current/amd64/jigdo-cd/debian-10.0.0-amd64-netinst.jigdo --2019-07-08 10:16:27-- https://cdimage.debian.org/debian-cd/current/amd64/jigdo-cd/debian-10.0.0-amd64-netinst.jigdo Resolving cdimage.debian.org (cdimage.debian.org)... 194.71.11.173, 194.71.11.165, 2001:6b0:19::165, ... Connecting to cdimage.debian.org (cdimage.debian.org)|194.71.11.173|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 26209 (26K) Saving to: ‘debian-10.0.0-amd64-netinst.jigdo’ debian-10.0.0-amd64 100%[===>] 25.59K --.-KB/sin 0.01s 2019-07-08 10:16:27 (1.88 MB/s) - ‘debian-10.0.0-amd64-netinst.jigdo’ saved [26209/26209] ### Hmm, wget finds the URL just fine, even though jigdo-lite says it ### ### doesn't exist... So install it from the local file instead of### ### the URL, even though https://www.debian.org/CD/jigdo-cd/ says to ### ### "supply that URL on the command line if you like".### $ jigdo-lite debian-10.0.0-amd64-netinst.jigdo Jigsaw Download "lite" Copyright (C) 2001-2005 | jigdo@ Richard Atterer | atterer.net Loading settings from `/home/council/.jigdo-lite' - Images offered by `debian-10.0.0-amd64-netinst.jigdo': 1: 'Debian GNU/Linux 10.0.0 "Buster" - Official amd64 NETINST 20190706-10:23 (20190706)' (debian-10.0.0-amd64-netinst.iso) Further information about `debian-10.0.0-amd64-netinst.iso': Generated on Sat, 06 Jul 2019 10:25:25 + - If you already have a previous version of the CD you are downloading, jigdo can re-use files on the old CD that are also present in the new image, and you do not need to download them again. Mount the old CD ROM and enter the path it is mounted under (e.g. `/mnt/cdrom'). Alternatively, just press enter if you want to start downloading the remaining files. Files to scan: - The jigdo file refers to files stored on Debian mirrors. Please choose a Debian mirror as follows: Either enter a complete URL pointing to a mirror (in the form `ftp://ftp.debian.org/debian/'), or enter any regular expression for searching through the list of mirrors: Try a two-letter country code such as `de', or a country name like `United States', or a server name like `sunsite'. Debian mirror [http://httpredir.debian.org/debian/]: File `debian-10.0.0-amd64-netinst.template' does not exist! ### Can't find that file either, despite using the mirror URL ### ### suggested on https://www.debian.org/CD/jigdo-cd/. I've also ### ### tried a half-dozen other randomly-selected German and ### ### Swedish mirrors, plus a few in the US in case it's just a ### ### European problem, all with the same results. ### --- cut here --- -- Dave Sherohman
Re: will Release come back for testing/updates at security.debian.org?
On Sun, Jul 07, 2019 at 03:22:40PM +0200, Salvatore Bonaccorso wrote: > That will be actually a permanent change, see > https://lists.debian.org/debian-security/2019/06/msg00015.html . The > intention was actually do to it already in earlier cycle, but was not > possible (cf. > https://lists.debian.org/debian-security/2015/12/msg00015.html). What was the intended method for people upgrading from pre-buster versions to find out about this change? Just wait for them to try to do an update, get an error message, and hope that they ask on the mailing list instead of just commenting out the security updates line? Perhaps an announcement on debian-security-announce (and perhaps also on debian-user) would be in order? Ideally one with a "PAY ATTENTION! THIS IS IMPORTANT!"-type subject line to minimize the chance of people missing it. -- Dave Sherohman
Re: How Buster release may affect Unstable?
On Fri, Jul 05, 2019 at 10:35:05AM -0300, Francisco M Neto wrote: > On Tue, 2019-07-02 at 12:23 -0400, Default User wrote: > > On Tue, Jul 2, 2019, 05:38 Dave Sherohman wrote: > > > I think the core misunderstanding here is that you seem to be assuming > > > that, when a new stable comes out, a new unstable is created to go with > > > it. > > Well... maybe? I mean, certain developers or maintainers may be aware of > the release cycle and delay their uploads into unstable until after the new > stable is released. In that case, Sid should experience an unusually high > number > of updates over the next few weeks. Yes, true, there will be (are?) a lot of new uploads to unstable in the wake of the new stable release, but my impression was that the OP might have been thinking that stretch-unstable is going to be discontinued and replaced with a brand new buster-unstable (based on the stable buster release), which isn't the case. sid remains sid forever and will never be replaced with a different unstable. -- Dave Sherohman
Re: How to have password shown?
On Wed, Jul 03, 2019 at 03:00:24PM +0100, Brian wrote: > Most people mistype at some time; have you considered why your father > might be doing it? Logins with convoluted or complex passwords do not > help, so consider 12345678 or the date of his birthday. I'm tempted to > say that either would reduce mishaps. This would basically be my suggestion as well, since you want to get him in the habit of using a password rather than disabling passwords entirely. Just make it a password based on a simple, compact keyboard pattern, such as 1234 or (assuming a qwerty keyboard) qweasdzxc, so that he's not moving from one part of the keyboard to another and potentially making mistakes while doing so. -- Dave Sherohman
Re: Debian Perl or Brew Perl for production application?
On Mon, Jul 01, 2019 at 06:30:19PM +0200, to...@tuxteam.de wrote: > I tend to stick to Debian packages as my primary choice, resorting > to off-distribution packages when needed (e.g. not packaged for > Debian, or I /need/ a newer version). Of course it takes some foresight > to guess in advance whether you expect such a situation in the > future. > > Rationale: they mesh better with the flow of system updates/upgrades. > > I've found Perl packaging in Debian outstanding. The Debian Perl > packaging team does a damn good job indeed. Pretty much the same here. I was initially hired as a Perl developer, then gradually moved into more sysadmin duties and, in both roles, I prefer to stick with the Debian-packaged perl binary. It gets me security updates as needed and the only reasons I see a particular need for PerlBrew and the like are: 1) You need different compile-time options than Debian chooses 2) You need access to a feature that's only present in a newer-than- Debian Perl version 3) You want to have the "latest and greatest" for its own sake Personally, I've never encountered #1 or #2 in practice and if #3 mattered to me, then I wouldn't be running Debian stable in the first place. -- Dave Sherohman
Re: How Buster release may affect Unstable?
On Mon, Jul 01, 2019 at 03:34:55PM -0400, Default User wrote: > What if a new Stable release introduces a major change to the existing > distribution technology or methodology? > > For example, a new default filesystem is introduced. Or something like > systemd infects the distribution or its rate of metastasis accelerates, > etc. Or an important package management system or communication protocol > is superseded or falls into disuse, or is simply abandoned by its > developers or maintainers. > > I was wondering if an existing Unstable setup could diverge so far from > Stable that major surgery would be necessary, or even complete replacement > with Stable, followed by conversion to contemporaneous Unstable. I think the core misunderstanding here is that you seem to be assuming that, when a new stable comes out, a new unstable is created to go with it. This is not the case. *NOTHING* ever goes from stable into unstable. *EVERYTHING* in stable[1] got there by way of unstable (with a stop off in testing along the way). If a major change happens in stable, then it already happened some months or years ago in unstable: - New filesystems start in unstable, then move to stable. - systemd for Debian was first implemented in unstable, then made its way into stable. - If apt were to somehow be replaced, that process would happen in unstable and the new package management tools would first appear there, before migrating into stable. So, no, a new stable release would never break unstable. Any breakage that may happen would be flowing in the other direction (something coming from unstable breaks stable), and even that is extremely rare. [1] ...except security updates, which have their own path into stable that doesn't pass through unstable, but they're not going to be introducing major changes anyhow. -- Dave Sherohman
Re: Can't install addons for firefox
On Sun, May 05, 2019 at 07:29:55PM -0400, Dan Ritter wrote: > No, Mozilla really screwed up. Understatement of the month, if not the year. And yet, on the Mozilla blog, all the comments are "oh, you're so awesome for working on a weekend to fix this!", completely ignoring that there wouldn't have been a problem to "heroically" work all weekend to solve if they'd just done things right (staying on top of cert expirations, not trying to funnel everything through a single point of failure, etc.) in the first place. > Try installing > > https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi > > And your problems should go away immediately. Thanks! The Mozilla blog just says to get the updated version, no mention of how to install the updated cert directly. I did still need to uninstall/reinstall my add-ons before they started working again (I assume it would have eventually revalidated them on its own, but I didn't have the patience to wait for that) but everything appears normal again after doing that. And all my settings appear to have survived across the uninstall/reinstall cycle, even! -- Dave Sherohman
Re: Can't install addons for firefox
On Sun, May 05, 2019 at 10:52:56AM +1200, Ben Caradoc-Davies wrote: > Setting about:config / xpinstall.signatures.required to false fixed > extensions for me for firefox 66.0.1-1 amd64 on Debian sid and for Firefox > 66.0.2 on Android. I needed to restart Firefox on Debian. When I tried that yesterday, it allowed extensions to be reinstalled (yes, I was one of those who tried to fix this problem by uninstalling and reinstalling my extensions), but not all plugins actually worked in this state. Most notably, NoScript displayed no icon on the toolbar (just a blank space with a tooltip) and did not appear to actually do anything. Its settings were also inaccessible, both through the (missing) popup menu and via the list of installed add-ons (in which case I got a blank grey page with an endless "loading" spinner animation). Based on this, it appears that xpinstall.signatures.required may be no more than a partial solution. (Although it's also possible that something may have been broken in the uninstall/reinstall process.) -- Dave Sherohman
Re: Making a modal window
On Mon, Dec 10, 2018 at 11:24:33AM +, Brian wrote: > It wasn't any plan for layers of secutity which surprised me but > the desire to add to the existing username/password login scheme > with extra (unspecified) questions. Dan Ritter's reply included some off-list clarification from the OP: > Actually the app I'm developing is for school's computer lab. In our > school's computer lab, if someone wants access the computer, they > should make a entry in a register stating the name, purpose, upto the > time they want to use. > > I'm making the same app in a computer for the computer. No user should > be able to use the computer without filling the form. We can assume > normal computer users and not so of advanced level. As Dan pointed out, you should be able to determine the user's name from their login information and the duration of the session is also logged automatically, so that really just leaves the "purpose" as the only thing which still needs to be collected separately. -- Dave Sherohman
Re: perl; Trying to get File::stat to work
On Fri, Oct 19, 2018 at 09:47:11PM -0500, Martin McCormick wrote: > I am a member of a perl discussion list but it seems to have gone > away Your actual question has already been answered, but, for future reference, PerlMonks (https://www.perlmonks.org/) is still around and there are also several Perl folks who frequent StackOverflow (https://stackoverflow.com/), so you can generally get good answers to Perl questions pretty quickly from either of those sites. -- Dave Sherohman
Re: utilities
On Tue, Sep 25, 2018 at 01:24:48PM +0200, Thomas Schmitt wrote: > But i am not sure whether the official classification in > https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities > of the first three priorities really matches the idea of a set of > "standard [system] utilities": > > "standard >These packages provide a reasonably small but not too limited >character-mode system." > > I.e. no X Window System: > https://tracker.debian.org/media/packages/x/xorg/control-1%3A7.7%2B19 I would not consider X[1] to be "standard" on anything other than a desktop workstation. I certainly don't install it on the vast majority of the machines I manage. > No command line CD/DVD/BD burning: > https://tracker.debian.org/media/packages/c/cdrkit/control-9%3A1.1.11-3 > https://tracker.debian.org/media/packages/d/dvd%2Brw-tools/control-7.1-12 > https://tracker.debian.org/media/packages/libi/libisoburn/control-1.4.8-3 Sounds pretty far from "standard" to me. Bordering on "esoteric", even. Again, CD/DVD/BD burning at all is generally only applicable to end-user systems[2] and, given that X is usually installed on such systems, I would expect GUI burners to be used much more widely than CLI programs. [1] Specifically, an X server. X client applications are often useful on non-desktop systems. [2] And, I would suspect, a rather small subset of end-user systems, at that. I only know one person who burns optical media these days, and that's to back up large numbers of photos whenever her hard drive fills up. -- Dave Sherohman
Re: Apache HTP-Server won't fork more than 3000 processes.
On Tue, Sep 18, 2018 at 12:14:11AM +0200, Martin wrote: > I have an issue with Apache's HTTP-Server 2.4. It says 'Resource temporarily > unavailable: AH00159: fork: Unable to fork new process'. I know, there are > some hits with Google, but there is no solution to me. > Systemd knows about a task limit of 6000. mpm_prefork_module is set to > 'ServerLimit 4000' and 'MaxRequestWorkers 4000'. ulimits are set to unlimited. > I also see in the kernel log 'cgroup: fork rejected by pids controller in > /system.slice/apache2.service'. But this does not correlate with the httpd's > messages from above, that comes only from time to time. > Why does this thing stop forking at about 3000 processes? I have a (not just > one) Red Hat 6 in parallel, that one does. "fork: Unable to fork new process" sounds to me like a system-level error, coming from fork itself, not an apache configuration issue per se. Have you checked for available resources on the system? Apache processes are fairly heavy in terms of memory and CPU usage, so I'd expect you to need a real beast of a machine to handle even 3000 apache processes, never mind 6000. -- Dave Sherohman
Re: Encrypted e-mails?
On Thu, Sep 06, 2018 at 03:44:22PM +0200, Torben Schou Jensen wrote: > We have smartphones with software from Apple and Google, but we are unsure > if they look in our data. Don't be silly. Of course they do. > But it is still very common to send unencrypted e-mails, open post cards. > So why not use OpenPGP to encrypt e-mails, it is free, I am trying to find > out how to? Can't speak for anyone else, but... I don't give a damn. I'm sending this message to a public email list that anyone can subscribe to, and I know that it's archived in many, many places, several of which can be browsed by the general public. It is not private, by design, so why would I bother with encrypting it in transit? If I were transmitting information that I actually wanted to keep secret, I wouldn't put it in the body of an email at all. The current push for enhanced privacy is all well and good, but the crusaders often forget that there's a lot of information out there which is intended to be public or which people simply don't care if it becomes public. There is absolutely no need to encrypt such information, therefore "encrypt everything" is not the moral imperative they make it out to be. (There's an argument to be made for using cryptographic signatures to validate the authenticity and integrity of messages, but that doesn't require encrypting the actual content itself.) -- Dave Sherohman
Re: mailing list vs "the futur"
On Thu, Aug 30, 2018 at 01:35:35PM -, Dan Purgert wrote: > [*] Please you one last holdout using our ancient FTP service, let's > move to the 21st century and use SFTP, please? Last week, we decommissioned an ancient server[1] and then got a call two days later from an academic complaining that his web site had disappeared. One of my predecessors had set him up with an arrangement where he FTPed his files to this ancient server, then the actual web host ran a daily cron job to scp files into production. We somehow managed to convince him that the easiest solution would be for him to use SFTP directly to the web server instead, and thus my last FTP user fell. Being rid of that protocol felt even better than I had anticipated. [1] I don't know how old it was exactly - it was here before I started - but it was running a version of Red Hat that was EOLed over a decade ago. -- Dave Sherohman
Re: mailing list vs "the futur"
On Fri, Aug 24, 2018 at 07:23:15PM +0100, mick crane wrote: > mailing list are great until one of the threads gets really, really, really > long ...and then they're *REALLY* great. The only problem I can ever recall seeing with mailing lists and long threads is when people don't trim the posts they're replying to. -- Dave Sherohman
Re: Fail2Ban Question: Can I do this without restarting the service?
On Fri, Aug 17, 2018 at 05:28:50PM -0400, cyaiplexys wrote: > While I don't travel, the co-admin travels a LOT and doesn't always stay at > hotels. Sometimes they are on the road, getting wifi other places, etc. So > again, probably not possible to even get a good range. Yes, agreed, you probably will need to open your ssh port to the world. > >>Can I do this too? > >> > >>ufw deny 22/tcp # Deny connection to port 22 (ssh default port) > > > >You could, but there's generally no point because all ports are denied > >by default. You usually don't need to create specific deny rules unless > >you have a port that you want to have open to the world, but then close > >it for specific addresses, or if there's an IP address that you want to > >allow access to all ports, except for a few specific ports. > > But (unless I was mistaken) wasn't port 22 open by default for ssh? So > wouldn't I have to block it once I change and open the other ssh port? No, it's not open by default. That's why it's necessary to set up the "allow port 22 from..." (or whatever your alternate ssh port might be) rule before turning the firewall on with "ufw enable". If you've already opened port 22, then change your ssh port after enabling the firewall, you would handle this by adding an allow rule for the new port and then (after establishing a new ssh connection on the new port) deleting the "allow port 22" rule rather than by adding a "deny port 22". To do this, run "ufw status numbered" to find the number of the rule you want to remove, then "ufw delete [rule number]". (Handy tip: If you want to add a new rule that's similar to an existing rule, but can't remember the exact syntax, you can "ufw delete [the existing rule]" and say "no" when it asks to confirm the deletion. The confirmation message includes the command used to create the rule, so you can just copy/paste it and change the details as needed to create the new rule.) -- Dave Sherohman
Re: Fail2Ban Question: Can I do this without restarting the service?
is stuff is the same for Debian and Ubuntu as > for fail2ban/ufw?) I have limited experience with Ubuntu, but my impression is that their differences (aside from release schedule) are primarily dealing with end-user-focused applications. Networking and firewall management are deep enough in the guts that I'm 99% sure they'll be the same in both distros. -- Dave Sherohman
Re: Fail2Ban Question: Can I do this without restarting the service?
On Thu, Aug 16, 2018 at 02:07:02PM -0400, cyaiplexys wrote: > See, that all is way over my head. I don't understand this stuff as I'm > pretty much a total beginner in this. OK, fair enough. Let's see what help I can offer. > Does Debian and Debian based systems have the firewall installed and > running by default? No. For general-purpose firewalling, I would suggest installing ufw (`sudo apt-get install ufw`), as it's much simpler to manage than using iptables (the underlying firewall control scheme used by both ufw and fail2ban to communicate with the kernel) directly. After installing ufw, the following commands should get you started (all of them need to be run with sudo or from a root shell): ufw allow to any port 22 from [your IP address] proto tcp (If you're using ssh to connect to the server, you *must* do this one before enabling the firewall, or else you'll lock yourself out. If you need to connect with ssh from multiple addresses, you can either run it multiple times with different addresses, or specify a network in CIDR notation.) ufw enable (Starts the firewall.) ufw logging off (...because it will otherwise flood your logs with reports of pretty much every packet recieved on the network interface.) ufw allow 80,443/tcp (Opens port 80 (http) and 443 (https) for connections from anywhere on the internet.) Repeat the last one with the appropriate port numbers for any other service that you want to make publicly available. > I hvae no idea how to jail or whatever in fail2ban. Sounds that's what I > want to do. Detect IP addresses hitting the server 1000 times in an hour and > then ban those for a good long while (week sounds good). That's pretty much exactly what fail2ban is intended to do. A "jail" is just fail2ban's term for a rule for what activities aren't allowed and how to handle IP addresses which break the rule. Unfortunately, adding a custom jail requires changes to multiple files, but I can at least give you specific details on how to create this particular one. Again, these files need to be created or edited using sudo or from a root shell. First, you need to create a filter definition. Create the file /etc/fail2ban/filter.d/apache-missing-local.conf containing: --- [Definition] failregex = [^ ]+ [^ ]+ \[[^]]+\] "[^"]+" 40[04] [0-9]+ --- Lines matching the failregex (an apache log line for a 404 error) count as "failures". Next, you need to define a jail which uses that filter. Create the file /etc/fail2ban/jail.local (or edit it if it exists, but I don't think it exists by default) and add: --- [apache-missing-local] enabled = true port = http,https filter = apache-missing-local logpath = /var/log/apache2/*access*.log maxretry = 1000 findtime = 3600 bantime = 604800 ignoreip = 127.0.0.1 --- 'port' is the list of ports to block when an address is put in the jail. 'logpath' is the list of logfiles to monitor for offending entries (in this case, all log files in /var/log/apache2 with "access" in their names). 'maxretry' is the number of times an address can break the rule before getting jailed. 'findtime' is how long (in seconds, 3600 = 1 hour) the retries are remembered. And 'bantime' is how long (in seconds again, 604800 = 1 week) the address should remain jailed before it is released and allowed to access your service again. 'ignoreip' is a list of IP addresses which should never be blocked. After setting up these files, you can either restart fail2ban or run `sudo fail2ban-client reload` to activate the new jail. > I wish there was an easy tutorial for doing these things. It would be nice, yes. I've figured out everything in this mail by reading man pages and examining the existing config files. Good tutorials would have made that a lot easier. -- Dave Sherohman
Re: Fail2Ban Question: Can I do this without restarting the service?
On Wed, Aug 15, 2018 at 09:29:58PM -0400, cyaiplexys wrote: > Is there a better way to do this? I have a cron job that gathers IP > addresses that get more than 1,000 hits from the apache log file and that > gets put in the ip.blacklist.perm file. If (as the filename implies) you want to block these addresses permanently, then why are you using a tool designed to manage blocks dynamically (fail2ban)? Just use your preferred firewall management tool to add a rule to block them outside of fail2ban. For example, I manage my firewalls with ufw, so I would use 'ufw deny from $IP_ADDR'. It takes effect instantly, with no need to restart anything, and will be persistent across reboots. If you don't actually want them to be permanent, then you could instead create a fail2ban jail which detects IP addresses which have generated 1000 incoming requests to ports 80/443 within the last 60 minutes (or whatever timeframe your log analysis script looks at) and bans them for a week (or however long you like), without needing to wait for the log analysis script to run first. And you can also whitelist certain IPs in the jail config, if there are internal service monitoring machines or whatever which legitimately generate levels of traffic which would normally trigger a ban. -- Dave Sherohman
Re: mailing list vs "the futur"
On Fri, Aug 10, 2018 at 08:29:34AM -0400, Rich Kulawiec wrote: > Correct. Procmail uses a set of rules to decide what to go with messages > presented to it; those rules are usually based on the contents of message > headers, but don't have to be. For example, for this mailing list: > > :0: > * ^X-Mailing-List:.* > /home/rsk/linux/debian-user > > Translating, this means that any message which has the specified header > will be appended to the file named in the last line. I used to use procmail a couple decades ago, then I switched to Debian, and Debian installed exim by default, and I started using exim to sort my mail instead. My corresponding rule is: if $h_X-Mailing-List: contains "debian-" then save $home/Mail/deb/ finish endif No translation required. (And I prefer a single mailbox for all my debian lists, which is why I just match on "debian-" instead of the full name/address of the list.) -- Dave Sherohman
Re: As seen above: use of su vs sudo
On Tue, Aug 07, 2018 at 12:22:53PM +0100, James Allsopp wrote: > As far as I can see "su -" saves a lot of grief if you're the only admin on > a system. Tried sudo ing to a protected directory? Doesn't work. Works fine for me: dave$ sudo bash [sudo] password for dave: root# cd /some/protected/dir root# > Tired of entering your password every couple of minutes? Even without using sudo to start a shell, it (by default) remembers that you've already authenticated recently and you only have to re-enter your password if you go more than 15 minutes without running a sudo command. -- Dave Sherohman
Re: As seen above: use of su vs sudo
On Tue, Aug 07, 2018 at 08:07:56AM -0400, The Wanderer wrote: > On 2018-08-07 at 07:47, Martin wrote: > > The point is not, that ONE person needs a root password. All people > > intended to do privileged things will have to share this password. > > This is a security nightmare! > > If they're all trusted enough to be trusted with that password in the > first place, this isn't a problem, any more than the one person having > it is. > > If they aren't trusted enough to have that password, why are we > permitting them to do anything root-level in the first place? It's not just a question of trust, but also one of maintenance. What happens when one of the people with root access gets a new job? Using su and a shared root password: - Disable the person's account. - Change the root password. - Find a secure way to distribute the new password to all the people it's shared by. Using sudo: - Disable the person's account. - Remove the account from /etc/sudoers and/or the sudo group. Everyone else with root access is completely unaffected by the departure. -- Dave Sherohman
Re: Changing systemd startup timeout
On Wed, May 16, 2018 at 02:09:43PM +0200, Sven Joachim wrote: > Have you tried setting TimeoutStartSec rather than TimeoutStartUSec? > Though I have to admit that I did not perform a web search but cheated > by looking at the systemd.service(5) manpage, which mentions the former > but not the latter. Whaddayaknow, that did the trick. Thanks! Strange, though, that you have to set it as TimeoutStartSec, but `systemctl show` displays it as TimeoutStartUSec. -- Dave Sherohman
Changing systemd startup timeout
Short version: How can I extend (or remove) the startup timeout for a single systemd service? Longer version: I'm running a galera cluster of three mariadb servers. It's been brought down twice because one node has detected an inconsistency, killed itself, and then systemd automatically restarted it. This is all good so far. The problem comes in when it tries to restart and, because it shut down in an inconsistent state, it wants to do a full state transfer to get back in sync with the rest of the cluster, which involves copying (potentially) 24G of data. Performing this transfer takes long enough that systemd times out, assumes the restart failed, and kills it, so it's not possible to bring the node back online without bypassing systemd and running mysqld_safe manually. Based on some web searches, I've tried using `systemctl edit mysql` to set "TimeoutStartUSec=infinity", but this does not appear to actually have any effect, even after reloading the systemd daemon: # systemctl edit mysql # systemctl show mysql -p TimeoutStartUSec TimeoutStartUSec=1min 30s # systemctl daemon-reload # systemctl show mysql -p TimeoutStartUSec TimeoutStartUSec=1min 30s # systemctl daemon-reexec # systemctl show mysql -p TimeoutStartUSec TimeoutStartUSec=1min 30s What do I need to do to make this actually work? Or is it possible to tell systemd to use a different method of determining whether mysqld has started successfully, so that it will recognize "SST in progress" as a valid "started" state? -- Dave Sherohman
Re: Origin of /var/run contents
Thanks! That was just what I needed. On Tue, Feb 27, 2018 at 12:46:50PM +0100, Martin S. Weber wrote: > On 2018-02-27 05:03:15, Dave Sherohman wrote: > > (...) > > So, is there somewhere that /run is initially populated from, > > (...) > > man 5 tmpfiles.d, see also its SEE ALSO. > > Regards, > -Martin > -- Dave Sherohman
Origin of /var/run contents
I've just made my first foray into creating systemd service files, and, although I got them to work with manual startup, they failed miserably on reboot. A short investigation revealed that this is because /var/run is not persistent across reboots. (It's a link to /run, which is a tmpfs mount.) The service file runs a shell script which starts the actual daemon (a starman server). The script runs as an unprivileged user, since we don't want starman running as root. However, /run is only writable by root, so starman can't create its pidfile. To work around this, I had created a subdirectory, /var/run/myapp, owned by the user I run starman as. This worked perfectly when it was set up, but, of course, that subdirectory vanished when the system was rebooted and, once again, starman couldn't create its pidfile. So, is there somewhere that /run is initially populated from, where I can create my myapp/ directory and set its ownership so that it will exist and be writable by the app's user when systemd starts it up? Or should I be going about this in a completely different manner? -- Dave Sherohman
Re: Dell Open Manage
On Mon, Feb 12, 2018 at 08:41:32AM -0600, David Wright wrote: > On Mon 12 Feb 2018 at 10:34:45 (+), Adam Weremczuk wrote: > > I'm referring to: > > > > http://linux.dell.com/repo/community/debian/ > > > > Does anybody know if jessie version works well on stretch? > > > > Or if an official release for stretch is going to be available soon? > > On stretch, if *they* don't know, I doubt you'll get much joy here. Coincidentally, earlier today I installed srvadmin-idracadm8 on stretch from deb http://linux.dell.com/repo/community/ubuntu jessie openmanage and racadm was able to read the network config from my drac with no problems. I haven't tried changing the network config yet, or any other operations, so I can't say whether it works completely, but it's at least partially functional. -- Dave Sherohman
Re: HTTPS - Your connection is not private - ERR_CERT_AUTHORITY_INVALID
> Now, when I open chromium or midori, I receive the error in the message > subject. > Any https url is not opened and a warning page is displayed instead. > > What could be the problem? Sounds like the root CA (Certification Authority) certificates aren't installed, making it impossible to establish trust in the individual site certificates. > And How to solve? First thing I'd try would be reinstalling the ca-certificates package. (Well, actually, the first thing I'd consider would be copying all important data to another location, then either restore a backup or reinstall the system, because it sounds like the problem it encountered is having widespread effects, so you're likely to encounter further weird problems like this in the future. But I assume that, in this case, neither of those is a viable option, so you're stuck with playing whack-a-mole as broken things are discovered.) -- Dave Sherohman
Re: Banishing UUIDs from grub
On Thu, Jan 18, 2018 at 06:42:41PM +0100, deloptes wrote: > Dave Sherohman wrote: > > What is the recommended method for preventing grub from using UUIDs to > > refer to filesystems in the current Debian stable distribution? > > what is the reason to avoid UUIDs? (if not very private) The specific system where this is an issue is a backing image used as the master for eight cloned developer virtual machines, so that each of our devs can have their own private space to work in which mimics the production server and can easily be reset to a pristine state by throwing out the clone and making a new one. In the cloning process, the disk and LVM volume UUIDs are discarded and new UUIDs are generated (which makes sense, because it's no longer the same disk or same volume), but grub is still looking for the original UUIDs and drops into a recovery shell when it fails to find them. At this point, I have the rest of the process automated. The one step that still requires manual intervention is walking grub through the first boot of the system and telling it to boot from (lvm/system) instead of (lvm/[vg UUID]/[volume UUID]). -- Dave Sherohman
Re: Banishing UUIDs from grub
On Thu, Jan 18, 2018 at 11:52:11AM -0500, Marc Auslander wrote: > Dave Sherohman <d...@sherohman.org> writes: > > >What is the recommended method for preventing grub from using UUIDs to > >refer to filesystems in the current Debian stable distribution? > > I don't know about "recommended" but could you put your own menu > entry into /etc/grub.d and make it the default? Short and sweet. Why didn't I think of that? Thanks! -- Dave Sherohman
Re: Banishing UUIDs from grub
On Thu, Jan 18, 2018 at 11:11:32AM +0100, Stephan Seitz wrote:
> On Do, Jan 18, 2018 at 03:31:30 -0600, Dave Sherohman wrote:
> >What is the recommended method for preventing grub from using UUIDs to
> >refer to filesystems in the current Debian stable distribution?
>
> In /etc/default/grub I have the option:
>
> # Uncomment if you don’t want GRUB to pass „root=UUID=xxx” parameter to Linux
> #GRUB_DISABLE_LINUX_UUID=true
That doesn't seem to be a complete solution for booting from an LVM
volume. I've enabled it:
$ grep UUID /etc/default/grub
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to
# Linux
GRUB_DISABLE_LINUX_UUID=true
and re-run update-grub, but /boot/grub/grub.cfg still has a mix of
device names and UUIDs:
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-c5bb6082-0b8b-46e5-a253-c4811a1f011a' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod lvm
insmod ext2
set
root='lvmid/wf5YhU-vt2F-uZM9-cVso-qn6Z-fdY9-iQO26v/sBd6ej-DTMK-RUxu-LuRW-MjLj-rRLf-C6OwT2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/wf5YhU-vt2F-uZM9-cVso-qn6Z-fdY9-iQO26v/sBd6ej-DTMK-RUxu-LuRW-MjLj-rRLf-C6OwT2'
c5bb6082-0b8b-46e5-a253-c4811a1f011a
else
search --no-floppy --fs-uuid --set=root
c5bb6082-0b8b-46e5-a253-c4811a1f011a
fi
echo'Loading Linux 4.9.0-5-amd64 ...'
linux /boot/vmlinuz-4.9.0-5-amd64 root=/dev/mapper/system ro quiet
echo'Loading initial ramdisk ...'
initrd /boot/initrd.img-4.9.0-5-amd64
}
My guess at explaining this would be that the GRUB_DISABLE_LINUX_UUID
flag is very literal and *only* affects whether "GRUB [passes]
"root=UUID=xxx" parameter to Linux", but not how grub itself identifies
the root device ("set root='lvmid/[UUID]').
--
Dave Sherohman
Banishing UUIDs from grub
What is the recommended method for preventing grub from using UUIDs to refer to filesystems in the current Debian stable distribution? --- In an attempt to head off a "but you really want to use UUIDs!" debate: The specific use-case I'm dealing with here is cloned virtual machines. When I clone them, the virtual disks' UUIDs are cleared and new UUIDs are assigned, which is as it should be. However, this causes the first boot to fail because grub can't find the UUID it wants to boot from, requiring me to manually boot the system through the grub rescue shell. Once the cloned VM is up and running, I can run grub-install to fix it, but the use of UUIDs prevents the cloned VMs from booting unattended until this is done. If grub were to try to boot from lvm/system[1] instead of lvm/UUID, that would remove the need for per-machine manual intervention. [1] ...and it will always and forever be lvm/system. Removable media and hardware which can autodetect in nondeterministic sequences are not concerns here. -- Dave Sherohman
Re: Filter logcheck reboot messages?
On Sat, Dec 09, 2017 at 04:49:09PM +0100, Sven Hartge wrote: > Ulf Volmer <u.vol...@u-v.de> wrote: > > On 09.12.2017 15:37, Sven Hartge wrote: > >> Richard Hector <rich...@walnut.gen.nz> wrote: > >>> Nobody else uses logcheck? Everyone is fine with how it works? I use it on a few dozen servers and I'm fine with how it works. Yes, the majority of the content in the reboot messages is just routine stuff, so I skip over it, checking only the first few lines and the last few lines for anything questionable, without bothering to examine every single line in between. Still good to have all the "businesss as usual" status messages in the middle, though, as that provides a record that I can go back and examine later if any problems do crop up, and which is independent of the machine itself, in case it's in too bad of shape to be able to examine its logs directly. > This is also the reason why I prefer logcheck over logwatch. > > With logcheck you define "normal behavior" and it gets filtered out. The > rest is then per definition "abnormal behavior" and gets send via mail. > > For logwatch on the other side you define the "abnormal behavior" > beforehand, which I find much more inconvenient and difficult, because I > mostly don't know if something is normal or not before I can see it. I actually use both. logcheck gives me quick (hourly) notice of abnormal events when they occur and logwatch gives me daily summaries of each machine's activity - not just unusual log messages, but also actions taken by fail2ban, numbers of failed login attempts by source, disk space status, etc. logwatch can also serve as a (slow) heartbeat for detecting machines which have failed or had their disks go into read-only mode (which prevents logs from being written, so logcheck has no log activity to report on) by setting up a script which knows what logcheck reports should be received each day and warns if any are missing. -- Dave Sherohman
Re: Embarrassing security bug in systemd
On Thu, Dec 07, 2017 at 09:37:25AM -0500, Roberto C. Sánchez wrote: > On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote: > > > > I no longer have any non-systemd machines handy to verify this on, but > > my memory is that I have *always* been able to use halt/poweroff/reboot > > commands from the console without requiring sudo or entering a password, > > and I've been using Debian since 2000ish, well before systemd was even a > > gleam in some programmer's eye. /sbin/shutdown may have also been > > freely available at the console, but I don't remember that one clearly, > > since I didn't use it all that often once I discovered the others. > > > I just did a fresh install of wheezy (7.11) with all defaults. Here is > what happened: > > testuser@debian:~$ cat /etc/debian_version > 7.11 > testuser@debian:~$ /sbin/reboot > reboot: must be superuser. > testuser@debian:~$ ls -l /sbin/reboot > lrwxrwxrwx 1 root root 4 Jul 14 2013 /sbin/reboot -> halt > testuser@debian:~$ ls -l /sbin/halt > -rwxr-xr-x 1 root root 15184 Jul 14 2013 /sbin/halt > > The situation is basically the same for /sbin/shutdown. Well, then. I stand corrected. Thanks for reminding me of what I'd forgotten! -- Dave Sherohman
Re: Embarrassing security bug in systemd
On Thu, Dec 07, 2017 at 11:26:45AM +1300, Ben Caradoc-Davies wrote: > Special privileges have been granted to console users for as long as I can > remember, long before systemd, because they have physical access to the > machine. Console users typically are also permitted to mount, unmount, and > eject removable media, and have access to audio devices. I think this is a key point that's been overlooked in the complaints about this behavior: It has nothing to do with systemd. I no longer have any non-systemd machines handy to verify this on, but my memory is that I have *always* been able to use halt/poweroff/reboot commands from the console without requiring sudo or entering a password, and I've been using Debian since 2000ish, well before systemd was even a gleam in some programmer's eye. /sbin/shutdown may have also been freely available at the console, but I don't remember that one clearly, since I didn't use it all that often once I discovered the others. But, then, even if I'm remembering incorrectly, it's still a policy matter, not a technical one. If the policy was changed at the same time as Debian switched to systemd, that's just a coincidence of timing and the same policy change could have happened while still under sysvinit. -- Dave Sherohman
Re: Older PHP for stretch
On Fri, Oct 06, 2017 at 09:08:55AM -0400, Roberto C. Sánchez wrote: > On Fri, Oct 06, 2017 at 07:35:28AM -0500, Dave Sherohman wrote: > > Does anyone know where I might be able to find a repo with PHP 5.3 for > > stretch? > This is highly inadvisable, unless you are deploying within a completely > trusted environment, as PHP 5.3 has been unsupported since August 2014. That's pretty much as I expected, although I had assumed anything older than jessie was already unsupported. wheezy might be worth a try, although we're also looking into whether a newer version of the app might be available which would run under a more current PHP version. Thanks! -- Dave Sherohman
Older PHP for stretch
Does anyone know where I might be able to find a repo with PHP 5.3 for stretch? It appears that one of the web apps we depend on is incompatible with PHP 5.4 or newer and the official stretch php5 packages are version 5.6.30. -- Dave Sherohman
Re: systemd says "org.freedesktop.systemd1.TransactionIsDestructive"
On Thu, Aug 31, 2017 at 07:40:50PM +0100, Jonathan de Boyne Pollard wrote: > That said, it does sound like, from the scant description given, you are > mis-using |su|. Do not abuse |su| to drop privileges > <http://jdebp.eu./FGA/dont-abuse-su-for-dropping-privileges.html>, from > |root| to |nobody|. There are proper tools for the job of dropping > privileges, which do not involve PAM and which will thus not hit this > problem. Moreover: do not abuse |nobody| for running dæmons > <http://jdebp.eu./FGA/dont-abuse-nobody-for-daemons.html>, if you are doing > that. Set up a proper rôle account. And, indeed, give the cron job > (whatever it is) directly to that rôle account's |crontab|. Thank you. This lecture, though misplaced, proved to be useful. While checking /etc/cron.daily to confirm that it's a Debian package, not anything I wrote, which uses `su nobody`, I found that /etc/cron.daily/locate calls updatedb.findutils with $LOCALUSER set to "nobody". updatedb.findutils then calls `su $LOCALUSER` multiple times, matching the multiple attempts to su from root to nobody that I see in auth.log. For my part, I suppose I'll resolve this by switching from locate to mlocate, which does its database updates as root, so it should have no reason to drop privileges, regardless of the method. In the larger picture, I suppose this qualifies as a bug in the locate package. But I will not file a bug against the package because, honestly, I don't believe that I understand the pieces in play well enough to make a convincing argument to the maintainer that it should be changed, much less what it should be changed *to*. -- Dave Sherohman
systemd says "org.freedesktop.systemd1.TransactionIsDestructive"
Since being upgraded from jessie to stretch, several of my machines have started emitting the following messages while processing cron.daily: (in /var/log/syslog) Aug 31 06:30:48 HOSTNAME systemd[1]: Requested transaction contradicts existing jobs: Transaction is destructive. (in /var/log/auth.log) Aug 31 06:30:48 HOSTNAME su[32025]: pam_systemd(su:session): Failed to create session: Input/output error Aug 31 06:30:48 HOSTNAME systemd-logind[1301]: Failed to start session scope session-11179.scope: Transaction is destructive. org.freedesktop.systemd1.TransactionIsDestructive The mention of freedesktop in one of the messages suggests that this may be somehow X/GUI related, but all machines which are doing this are headless servers with no X server installed, so they shouldn't be touching anything obviously related to freedektop.org. Googling "org.freedesktop.systemd1.TransactionIsDestructive" just gets me a handful of people having system startup/shutdown problems, which would seem to support the "it's GUI desktop related" assumption, but doesn't really provide any explanation of what's actually going wrong (if anything - systemd is rather chatty even when everything is just fine). Looking at the larger context in auth.log, this comes in the middle of starting up and shutting down several su sessions from root to nobody, all of which succeed aside from the one which generates these errors. So, in practical terms, what do these messages actually mean, beyond just "a su session failed to start"? Is it anything to be concerned about? -- Dave Sherohman
Re: Question to new network device names
On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote: > However, I'll point out that machines with this many network interfaces > are *by far* the exception rather than the rule; indeed, even machines > with more than *one* interface each of wired and wireless are reasonably > rare. In the home desktop space, perhaps. When you deal with rackmount servers, OTOH, four (wired) network ports is pretty standard these days. Of course, they're all on the same bus and using identical hardware/ firmware, so the "order might change based on which drivers load first" case still doesn't apply. > To the best of my awareness, the rationale for calling this "predictable > network interface names" is that, on a single computer which has > multiple network interfaces of a given type, this naming scheme makes > it possible to predict *from one boot to the next* what the name of each > one will be. On such a computer, this is extremely valuable. > > By contrast, on a computer which has at most one interface of a given > type, this naming scheme provides - so far as I can tell - no advantage > at all. > > What's more, when working on *multiple* computers of that latter type, > this naming scheme makes it impossible to predict *from one computer to > the next* what the name of the sole available interface will be. > > As such, IMO this naming scheme makes network-interface names > significantly *less* predictable in the real-world scenario which is > most commonly encountered. This closely parallels the move from using /dev/sdXn to UUIDs for referring to filesystems. Probably superior in theory and doesn't cause any issues as long as you're dealing with a single machine and unchanging hardware configuration... but then you have a drive failure, restore your backups onto new hardware, and you're hosed because the system wants to boot from a UUID that no longer exists. (Yes, you can recover from that situation - I know because I've had to do it - but it doesn't Just Work(TM) effortlessly.) -- Dave Sherohman
Re: Apache oddness on jessie => stretch upgrade
On Tue, Aug 22, 2017 at 11:49:50AM +0200, Sven Hartge wrote: > Dave Sherohman <d...@sherohman.org> wrote: > > Also, side question: I'm also manually running `systemctl enable > > apache2` after upgrading. > > You shouldn't need to do this, the maintainer scripts in the packages > will do this for you during the upgrade. > > *If* you need to do this to get a service started automatically during > boot, then something is wrong with your system. I've been doing it more just to be certain it was enabled, since I wasn't sure how to tell if it was already enabled or not. It probably wasn't actually needed. > > How can you tell whether something is enabled or not in systemd? > > `systemctl status` will tell you whether it's currently running or > > not, but I can't find any indication of enabled/ disabled in its > > output. > > , > | # systemctl status ssh.service > | ● ssh.service - OpenBSD Secure Shell server > |Loaded: loaded (/lib/systemd/system/ssh.service; enabled) > |Active: active (running) since Tue 2017-08-22 11:36:46 CEST; 11min ago > | Main PID: 812 (sshd) > |CGroup: /system.slice/ssh.service > |└─812 /usr/sbin/sshd -D > ` > > See the "enabled" at the end of the line starting with "Loaded:"? ... Well, that's embarrassing. How did I manage to never notice that in all the times I looked for it? Thanks! -- Dave Sherohman
Apache oddness on jessie => stretch upgrade
Yesterday, I started on upgrading my servers from jessie to stretch. It went mostly without incident at the time, but then apache failed to restart after logrotate did its thing overnight. Investigating the apache error log, it ended with: [Tue Aug 22 06:30:01.223322 2017] [mpm_prefork:notice] [pid 32366] AH00171: Graceful restart requested, doing restart apache2: Syntax error on line 146 of /etc/apache2/apache2.conf: Syntax error on line 2 of /etc/apache2/mods-enabled/access_compat.load: Cannot load /usr/lib/apache2/modules/mod_access_compat.so into server: /usr/lib/apache2/modules/mod_access_compat.so: undefined symbol: ap_get_useragent_host The particularly odd part is that this seems to happen only on the first restart after the upgrade. If I manually `systemctl start apache2` or `apachectl graceful`, it successfully starts up with no complaints. I'll have to wait until tomorrow to see whether this recurs on the next logrotate run. Any ideas regarding what's happening here or how to prevent it (other than doing a manual apache restart immediately after upgrading, to get the failure out of the way)? Also, side question: I'm also manually running `systemctl enable apache2` after upgrading. How can you tell whether something is enabled or not in systemd? `systemctl status` will tell you whether it's currently running or not, but I can't find any indication of enabled/ disabled in its output. -- Dave Sherohman
Re: mailutils in stretch
On Fri, Jul 07, 2017 at 04:39:48PM +0200, Sven Joachim wrote: > Argh, I am sorry. I meant to say just the opposite by leaving out the > extra "not", In fact, various packages have been demoted from Priority > standard or important to optional in recent years. This includes the > venerable "ed" text editor for instance, and also any package providing > /usr/bin/mail. Apparently the reason is that they pull in an MTA which > is also no longer included by default. Which seems sensible to me BTW. It isn't? On one of the new stretch machines referenced in my original post, I get: ~$ dpkg -s exim4 | grep Priority Priority: standard -- Dave Sherohman
Re: mailutils in stretch
On Fri, Jul 07, 2017 at 09:41:33AM +0200, Sven Joachim wrote: > On 2017-07-07 02:06 -0500, Dave Sherohman wrote: > > What was the reason for omitting mailutils (and, specifically, a > > functional /usr/bin/mail binary) from the default strech install? > > For the record, mailutils have never been part of a default install, but > bsd-mailx (which also provides /usr/bin/mail) was until Jessie. I stand corrected. bsd-mailx does sound more familiar, now that you mention it, but mailutils was the (first) `mail`-providing package I found when I started looking with `apt-cache search`. > > That's kind of a standard thing to be there on *nix systems... > > For better or worse, a default Debian installation seems to not omit > various programs that have been standard on Unix systems. Yes, exactly, which is why I was so surprised by /usr/bin/mail's disappearance. > There are certainly reasons for that, and I don't think many people > use /usr/bin/mail to send or read mail these days. > Packages using /usr/bin/mail to send reports should depend on, or at > least recommend, bsd-mailx | mailx. The reports in question weren't from packaged reporting tools, but rather from random command-line programs being run with a command of the form `some-program 2&>1 | mail dave -s "some-program results"`. Is there a more "modern"/preferred way of doing this sort of thing, which will work in a default stretch install (and doesn't require adding headers to the program output to make it suitable for piping directly to /usr/sbin/sendmail)? Before someone points out that cron mails output to the user whose crontab it runs from, these commands aren't being run directly from a crontab. Most are in cron.(d/daily/weekly/monthly), which doesn't appear to support mailing the output to a non-root user or customizing the subject line into somthing more useful than "Cron <root@host> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )". -- Dave Sherohman
mailutils in stretch
What was the reason for omitting mailutils (and, specifically, a functional /usr/bin/mail binary) from the default strech install? That's kind of a standard thing to be there on *nix systems... (Yes, I've just spent the last couple days wondering why a couple new stretch servers I set up were mailing some of their reports, but not others, and finally noticed the "/usr/bin/mail: not found" errors associated with the missing reports.) -- Dave Sherohman
Re: glusterfs and qemu/kvm
On Thu, Jul 06, 2017 at 09:43:48AM -0400, Jason Wittlin-Cohen wrote: > The last post on the bug report indicates that this issue has been fixed. > The changelog for the fixed version states: > >* enable glusterfs support (glusterfs-common), in qemu-block-extra > > Stretch and newer contain qemu-block-extra, and it depends on > glusterfs-common. Ah, I missed that. I didn't go through the details of the final message because the "wontfix" tag is still there, so I assumed it still applied. However, even after installing qemu-block-extra and restarting libvirtd, it's still a no-go: ~$ sudo apt-get install qemu-block-extra ~$ sudo systemctl restart libvirtd ~$ cat gluster.xml gluster-test palantir ~$ virsh pool-define gluster.xml error: Failed to define pool from gluster.xml error: internal error: missing backend for pool type 10 (gluster) This is on a fully up-to-date stretch install (qemu 1:2.8+dfsg-6, libvirt 3.0.0-4, gluster 3.8.8-1). -- Dave Sherohman
glusterfs and qemu/kvm
I'm currently running a number of virtual hosts under qemu/kvm backed by iscsi storage and would like to move the storage onto glusterfs. Unfortunately, Debian's qemu does not come with gluster support. When searching for information on this, I came across this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775431 It was tagged wontfix in Oct 2015 and closed Dec 2016. The basic reason for the wontfix is that gluster is packaged in a way which makes it infeasible to provide gluster support in the core qemu package, or even to create a qemu-glusterfs package, and this in turn is because upstream does things in a way which would make it difficult to maintain a stable glusterfs-dev package. Has this situation changed at all since then? Assuming it hasn't, is there a recommended procedure for replacing the standard Debian qemu with a version which adds gluster support? -- Dave Sherohman
Re: Replace systemd
On Tue, Jul 04, 2017 at 07:08:03PM -0700, Patrick Bartek wrote: > Why not try a window manager and a panel? I'm so far behind the times[1]... What's a "panel" in this context? [1] I still use WindowMaker for my desktop. -- Dave Sherohman
Re: stretch, vim, cut and paste broken (and fix)
On Fri, Jun 30, 2017 at 10:36:52AM -0400, Dan Ritter wrote: > That's nice. It doesn't actually work for the X cut and paste > mechanism that I rely on, and it turns out that adding this > to my .vimrc: > > set mouse=off > > or > > set mouse="" > > does not work. That's odd. 'set mouse=' worked fine for me as an in-session fix and my long-term fix was to create a file at /etc/vim/vimrc.local containing: --- cut here --- " Don't silently ignore these settings in favor of those in default.vim let g:skip_defaults_vim = 1 " Middle-mouse should paste from system clipboard, NOT vim clipboard! set mouse= --- cut here --- Guess I never tried it in my own .vimrc, though, so perhaps default.vim is overriding that, then, in addition to vimrc.local. -- Dave Sherohman
Re: How did you update to stretch?
On Mon, Jun 26, 2017 at 01:27:42PM -0500, David Wright wrote: > By running upgrade before dist-upgrade, you reduce complexity by > maximising the compatibility of packages with each other. When > lenny was replaced by squeeze, even these two steps were > insufficient; the kernel and udev needed replacing as a pair after > the (lenny) upgrade and before the (squeeze) dist-upgrade. I was around for lenny => squeeze, but had forgotten about that. It could well be the explanation for my current procedure, though, which is: apt-get update apt-get install dpkg apt apt-get upgrade apt-get dist-upgrade The basic idea being to first get the latest tools in place, then do the simple upgrades, and save the complex ones for last. I also used to stage large upgrades in multiple steps, doing only a dozen or two packages at a time and selecting dependencies first, leaving dependent packages for later (when possible), again in the interest of keeping each batch of updates as simple as possible, but I've stopped doing that since the tools started distinguishing between manually-installed packages and those which were automatically selected to satisfy dependencies. -- Dave Sherohman
Re: [OT] Imperial measures
On Wed, Oct 05, 2011 at 02:54:42PM +, Curt wrote: A liter of water weighs a kilo and is one meter long (at sea level). A liter of water can be any length you want[1] (at any altitude), depending on its cross-section. [1] Well, OK, there is an upper limit, depending on how close you require the molecules to be in order to still be considered a contiguous liter of water. If we require them to be separated by a maximum distance of 2.75 angstroms (the diameter of a water molecule, according to a quick google search), that gives a maximum length of 1.656 x 10e14 meters, or roughly 28 times Pluto's mean orbital radius. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111006122646.ga23...@sherohman.org
Re: Worst Admin Mistake? was -- Re: /usr broken, will the machine reboot ?
On Tue, Sep 13, 2011 at 03:15:13PM -0700, Bryan Irvine wrote: On Wed, Sep 7, 2011 at 1:00 PM, Bob Proulx b...@proulx.com wrote: jacques wrote: by error most of the binaries in /usr are erased (killing rm :-( Everyone has made that mistake at some point. I know I have! Not me! Me neither! However, on my first attempt to back up a Debian system, I somewhat misunderstood the tar man page and entered: tar cvzf /dev/hda1 * -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110914121322.gm23...@sherohman.org
Re: too much context switching
On Mon, Jul 04, 2011 at 02:52:18PM -0600, ChadDavis wrote: Does the context switching means CPU switches it speed? Context switching means that the CPU has switched the process that it is executing. The context is the process's execution context, I believe, which contains it's execution stack, variables, etc. Yes, that's exactly what the context in question is. I'm not familiar with how the Linux kernel divides up CPU time between processes, but, if it does it based on clock cycles (X clocks to this process, then X to that one, etc.) rather than wall-clock time (0.01 seconds to this process...), then we can expect the number of context switches per second to correlate strongly with CPU speed, since there will be more X clocks slices per second to distribute. If any running software includes commands to yield CPU early, then a similar (but weaker) correlation can be expected, since that yield command will be reached more quickly each time that program runs, leading to more churn of executing processes. Perhaps more significantly, I would expect a strong correlation between context switches per second and the number of CPU cores, since each core will have its own process context and do its own switching and time slicing - I would generally expect a system that's running processes on four cores to have four times as many context switches per second as a system that's only using one core. It's just a side detail that, in general, CPUs with more cores also tend to have higher clock speeds. Anyhow, there are some good answers to the original question at http://serverfault.com/questions/14199/how-many-context-switches-is-normal-as-a-function-of-cpu-cores-or-other For a short and sweet answer, I'll turn to Microsoft and their Windows 2000 Server docs (http://technet.microsoft.com/en-us/library/cc938613.aspx): You can determine whether context switching is excessive by comparing it with the value of Processor\% Privileged Time. If this counter is at 40 percent or more and the context-switching rate is high, then you can investigate the cause for high rates of context switches. If, as in the OP, your CPU is 90+% idle, then you are *not* having problems caused by excessive context switching. (The reason they become problematic is because they suck CPU time away from doing useful things. If the CPU is idle, then it's obviously not having problems with wasting too much time on context switches.) -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110707095037.gh4...@sherohman.org
Re: [OT] Google search default lang.
On Mon, Jun 20, 2011 at 10:55:43PM +1000, Scott Ferguson wrote: On 20/06/11 18:35, Dave Sherohman wrote: Oh, if only it were that simple... Most internationalized websites (including Google) seem to have completely given up on Accept-Language headers[1] in favor of relying on IP geolocation. I'm an American expat living in Sweden, so my browsers are set to send Accept-Language: en-us, en, sv-se Despite this, every time my Google cookie expires, it sends me the Swedish version of the page. Setting language preferences on the client side does *not* work[2] for Google or most other sites. [1] apparently on the theory that most users don't know how to set their preferred lanuages, so the header specifies the browser's default instead of the user's preference [2] even though it damn well should Are you sure this is not also Google's geolocation feature? My point is that geolocation should not matter. Yes, I am physically in Sweden, however my Accept-Language header explicitly states that Swedish is NOT my preferred language. Documents should be provided in en-us if available, then en, and only sv-se if no English version is available, regardless of my location. How they determine my physical location (IP geolocation vs. approximating based on google's database of wireless access point locations vs. GPS vs. triangulating from cell towers vs. picking me out of a spy satellite image vs. whatever else) is completely irrelevant to this point. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110622083907.gc11...@sherohman.org
Re: [OT] Google search default lang.
On Sun, Jun 19, 2011 at 01:14:11PM -0300, Leandro DUTRA wrote: 2011/6/19 Lisi lisi.re...@gmail.com: Google - language tools (under advanced) - preferences Even better, set the system???s or the user account???s language. Oh, if only it were that simple... Most internationalized websites (including Google) seem to have completely given up on Accept-Language headers[1] in favor of relying on IP geolocation. I'm an American expat living in Sweden, so my browsers are set to send Accept-Language: en-us, en, sv-se Despite this, every time my Google cookie expires, it sends me the Swedish version of the page. Setting language preferences on the client side does *not* work[2] for Google or most other sites. [1] apparently on the theory that most users don't know how to set their preferred lanuages, so the header specifies the browser's default instead of the user's preference [2] even though it damn well should -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110620083540.gb11...@sherohman.org
Re: how to get to runlevel 3
On Fri, Jun 10, 2011 at 07:42:25AM +0200, Mark Panen wrote: Been googling for this with no success. I have tried init 3 and teinit 3 and the runlevel command shows i am at runlevel 3 Then you are in runlevel 3. If your true objective is to get to runlevel 3, you have succeeded! but X is still on and i cannot install a Nvidia driver. Unlike Red Hat-derived distributions, Debian leaves it up to the individual sysadmin to define the significance (if any) of runlevels 2-5. By default, they are all identical. If X is starting by default, then you must have installed an X display manager. Unfortunately, it's been so long since I last did a default Debian install that I have no idea which one might have been automatically installed (I'm assuming you didn't explicitly install one, since you don't want what it does to happen), but you should be able to find the running display manager with ps ax | grep dm Look for a process named something like xdm, wdm, gdm, kdm, etc. Assuming you found xdm, you can then shut it down with /etc/init.d/xdm stop If, on the other hand, you just need to get to a real console and don't need to shut X down completely, a simple ctrl-alt-F1 will do that. (Although, if your purpose is to install nVidia drivers, you probably will need to shut X down.) -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110610065722.gx25...@sherohman.org
Re: how to get to runlevel 3
On Fri, Jun 10, 2011 at 09:37:15AM +0200, Mark Panen wrote: yes, as Frank said /etc/init.d/kdm stop works, one thing i don't understand about runlevels though is, when i reboot, i still get X which i want but, who -r run-level 2 2011-06-10 09:01 last=S why is X running at runlevel 2 and not 5? Your who -r output says the last runlevel was S (the capital letter), not 5 (the numeral). Per man 8 init: Runlevel S is not really meant to be used directly, but more for the scripts that are executed when entering runlevel 1. For more information on this, see the manpages for shutdown(8) and inittab(5). When the system is in runlevel S, it hasn't fully booted. X just hasn't been started yet at that point. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110610075016.gz25...@sherohman.org
Re: Poll Summary Poll 1b - What Smartphone do you use?
Ah, what the heck... I'll play: Sony Ericsson Xperia X10i, Android 2.1, 3, Sweden APD: 40, 32, 13 (Yes, Sweden has a cell carrier named 3. No, I have no idea how they managed to get that approved as a company name.) -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110517133727.gb25...@sherohman.org
Re: Let's say you never want to upgrade from Lenny...
On Tue, Apr 05, 2011 at 05:55:30PM +0200, Klistvud wrote: The leap from Lenny to Squeeze is not that big, after all. It's just like having Lenny on steroids. There are just too many goodies in Squeeze not to upgrade. What's the big fuss? I've upgraded my better half and our two kids to Squeeze and, apart from the new boot theme/wallpaper, they never even noticed it. So, if I'm following this correctly, you should upgrade from lenny to squeeze because it's chock full of goodies, but (aside from the boot theme/wallpaper) you'll never notice whether those goodies are there or not? If the goodies aren't noticable, then they don't sound like a very compelling reason to upgrade. (I'm not saying you shouldn't upgrade, just that those two paragraphs seem to contradict each other.) -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110406071407.gd32...@sherohman.org
Re: New policies?
On Mon, Feb 14, 2011 at 04:48:44PM -0600, Boyd Stephen Smith Jr. wrote: For the irksome case where a proprietary protocol is changed out from under Free Software in a stable release, Debian has already had a mechanism for fixing this, for a while. First, the change required to support the changes in the protocol are applied to the stable version of the software. Then, after some internal testing, a VUA ts published and the updated Debian package is uploaded to volatile. Concurrently, this update might also be published to stable-proposed-updates. If there are complaints with the new package, these are addressed in the same repositories. Assuming the package is in good shape by the next point release, the new package is included in that point release. ... This is similar to a security update in some ways, but it doesn't have a dedicated team and repository mainly due to the relative importance. The sticking point is largely the same, too; the fix must be cherry-picked / backported to the version of the software that is in Debian. If no one will do that work, that is proof of lack of interest in the bug fix. ...and *this* is why I love Debian. Stable is rock-solid without bringing in all the new features (and their accompanying new bugs) every time that upstream drops a new latest and greatest version. Aside from once every couple of years, it doesn't change except to address major problems and, even then, the change is limited to only the fix for the problem instead of adopting unrelated updates just because they're there. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110216115637.gf18...@sherohman.org
Re: Sticking with Lenny
On Tue, Feb 08, 2011 at 11:27:55AM +, Tony van der Hoff wrote: deb http://ftp.uk.debian.org/debian stable main contrib non-free ... What happens in this case? Presumably updates will be taken from the new stable repository? Correct. Should I be specifying lenny instead of stable, Yes, if you want to stay on lenny until further notice. Personally, I always use the version names, so I'm not 100% certain that it's still around, but I believe you could also use old-stable to continue tracking lenny (at least until wheeze comes out, at which point old-stable will become squeeze). or am I already too late to do that? If you've already done any updates which have installed packages from squeeze, then it's too late with respect to those packages (apt won't automatically downgrade the squeeze versions back to a lenny version), but, aside from that, changing from stable to lenny shouldn't cause any problems. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110208115901.gn2...@sherohman.org
Re: Let's talk about HTTPS Everywhere
On Thu, Jan 20, 2011 at 03:26:31PM +, Camaleón wrote: In regards to http cookie hijacking the first and foremost a programmer would ask himself is do we really need to *constantly* generate a write/ read operations of the cookies for *all* the tasks?. Unfortunately, if the site is to exist within a single base URI, yes, we do need to *constantly* read cookies. That's the way browsers work - if the browser holds any cookies related to a given URI, it will send those cookies on *every* request to that URI. The cookies are not requested on a per-fetch basis by the server. The only way around this is to have separate /public and /authenticated spaces within your app's URI space and set all cookies to apply only to the /authenticated space. This isn't a viable solution these days, however, as it means that documents in the /public space will have absolutely no access to any information regarding the user or his session, so it won't be able to do things that users have become accustomed to, such as showing who you're logged in as (or even whether you're logged in at all, making any login or logout links within the /public space problematic, at best). (Well, OK, there is one other way around it: Discard the stateless HTTP protocol and replace it with a protocol based on persistent connections so that you don't have to fake persistence by using cookies to re-identify yourself every time you talk to the server, but there's no way that's happening any time soon.) If the data, that now is being exchanged between the server and user's computer by means of cookies, is to be stored in the server itself in a database, most of theses attacks could be prevented. Any decent site will only use a single cookie containing a random session ID and store all additional data on the server itself, keyed to that ID. In this (extremely common) scenario, the only thing being exchanged between the server and the user's computer by means of cookies is this identification token; storing it solely on the server and not repeatedly exchanging it would mean that the server is not able to identify the user. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110121092126.gh3...@sherohman.org
Re: Let's talk about HTTPS Everywhere
On Wed, Jan 19, 2011 at 02:47:11PM +, Camaleón wrote: On Wed, 19 Jan 2011 07:17:58 -0600, Dave Sherohman wrote: When dealing with sites which use session cookies, public navigation *is* sensitive data, as every request sent will include the cookie(s) which identify you and an attacker who gains access to that data would be able to use those cookies to impersonate you for the lifetime of that session, as demonstrated by the recent uproar over FireSheep. Data stored in cookies is not what I understand for sensitive. What kind of information do you think are cookies managing? As I said earlier, websites which use persistent sessions store the session id in a cookie. While this cookie does not contain any data which is meaningful outside of the context of your persistent session, it is somewhat sensitive in that an attacker would be able to impersonate you by cloning your session cookie. This would then allow them to create or access content on the site which issued the cookie as if they were you, potentially gaining access to more conventionally sensitive information or fraudulently posting from your accout, for the remaining lifetime of the session. Some sites do associate the originating IP address with the session data to help protect against session hijacking, but this is not overly widespread and, even when it is employed, it has issues with proxies (which can cause multiple users to appear on a single address) or reverse proxies (which can cause a single user to appear on multiple addresses), so https really is the only surefire way to prevent it. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110120093603.gg3...@sherohman.org
Re: Let's talk about HTTPS Everywhere
On Wed, Jan 19, 2011 at 12:57:48PM +, Camaleón wrote: On Wed, 19 Jan 2011 03:29:15 -0800, S Mathias wrote: 3) Can someone trust this Add-on? Is it safe to install/use? I don't like/trust anoymous (even encrypted) proxy sites. HTTPS Everywhere is not a proxy site, encrypted, anonymous, or otherwise. It causes your browser to request that the sites you visit use HTTPS rather than cleartext HTTP when communicating (directly) with you. Nothing more, nothing less. 4) If it's so great why isn't it more prevalent? - SSL traffic is heavy and slow ... My opinion is that I don't want to encrypt all the traffic, at least not with the slow DSL connections/hosts we have now (loading a single page will take seconds). I don't know where you get this idea. SSL traffic is no different on the wire than any other data traffic. There is a cost in processing overhead for running the encryption algorithms on the client and on the server, but it does not incur any additional bandwidth requirements and, with modern hardware, the additional processing cost is negligible. - There no need (normally) for encrypting public navigation (see the note below) ... I prefer to leave the SSL/TLS for sensitive data (logins, etc...). When dealing with sites which use session cookies, public navigation *is* sensitive data, as every request sent will include the cookie(s) which identify you and an attacker who gains access to that data would be able to use those cookies to impersonate you for the lifetime of that session, as demonstrated by the recent uproar over FireSheep. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110119131758.gf3...@sherohman.org
Re: Does everything depend on everything?
On Fri, Oct 30, 2009 at 09:49:08AM -0400, Celejar wrote: Why does anything have to be wrong? It just means that you'll have to wait to upgrade the core packages until newer versions of the optional packages, compatible with the new core packages, become available. I assume that you're running testing or unstable? This sort of thing is not uncommon with those flavors, IIUC. Expected, even. That's why they're *called* testing (as in, it's not fully-tested yet, so it may break) and unstable (as in, it's not stable). -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] List policy - [Was: Could you recommend CD/DVD writer program?]
On Mon, Oct 12, 2009 at 11:29:57PM -0500, Boyd Stephen Smith Jr. wrote: It is semi-on-topic for this list to discuss work-arounds for Debian-provided clients, most of which boil down to using Reply-To-All and then editing the To/Cc lines to match list policy. Actually, I'd say that the majority of suggestions boil down to use a better email client. I know mutt supports reply-to-list (I'm using it right now) and I'm pretty sure I've seen people here saying that Thunderbird supports it natively in the latest version (and with a plugin in earlier versions). A couple others have also been mentioned, though their names elude me at the moment. Use reply-to-all and edit to/cc seems to be the fallback position for when the person who doesn't like the way the list works says they can't/won't switch clients. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Could you recommend CD/DVD writer program?
On Tue, Oct 13, 2009 at 07:23:30AM +0400, Mark Goldshtein wrote: On Mon, Oct 12, 2009 at 1:17 PM, Dave Sherohman d...@sherohman.org wrote: Granted, for most lists, the substantial majority of replies are intended to go to the list, but the greater degree of harm caused by inadvertently publicizing private information is, I believe, large enough that the average harm-per-reply (i.e., expected harm from a mis-send times the odds of a mis-send) is still lower without setting reply-to. I'm not a list admin here, but that seems to me like a pretty good reason for the current policy. Still see no reason not to have Debian Mailing List in 'Reply-To' field. People who subscribed to public mailing list undoubtedly almost in 100% cases want to reply to that mailing list, not to the original authors. Is that not reasonable? The position I was trying to explain in my earlier message was that, even though 99% of replies to mailing list messages are intended to go to the list, directing an intended-private message to the list causes over 100 times more harm than a message intended for the list being inadvertently made private. The Debian list policy is, therefore, reasonable, because it minimizes the overall total harm caused by misdirected messages. Reasonable people can (and clearly do) disagree, but that's why I favor maintaining the Debian list policy of not injecting Reply-To: headers. My main point, really, was just that the current policy is not merely a case of being as mule-headed as possible about this, for no good reason, RFCs-be-damned. There are actual reasons behind it, even though some may not agree with them. That said, some other posts in this thread have mentioned a tendency of d-u members to become irate when replies are sent with 'reply-to-all' and they receive two copies of the response, one privately and one via the list. This does strike me as unreasonable, particularly given that so many people continue to use broken email clients that don't provide a reply-to-list function. Although dual-replying is marginally inefficient, it's ultimately benign, easily ignored, and, if it really bugs you that much, I've seen many procmail recipes posted here for filtering them out automatically. There's no reason to get on anyone's case for using reply-to-all. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Could you recommend CD/DVD writer program?
On Sun, Oct 11, 2009 at 06:28:29AM -0500, Mark Allums wrote: The fact that so many people have a problem with this should tell the maintainers something. They are being as mule-headed as possible about this, for no good reason, RFCs-be-damned. Am I correct to infer from your final clause that you are aware of some RFC which states that mailing lists SHOULD or MUST add reply-to headers directing responses back to the list? If so, please cite the RFC number and/or provide a link to it, as I am aware of no such RFC. And sometimes I forget. I have to remember two behaviors for different lists. I'm not young anymore. No one should get POed at anyone else for not changing the addressing, because we may not be able to do better. Sometimes I forget, too. I'm sure everyone does. That's human nature. So what happens when someone forgets? With reply-to set to direct responses back to the list, a response which was intended to be private becomes public. With no reply-to, a response which was intended to be public becomes private. Perhaps your experiences have been different than mine, but, as I see it, publicizing something intended to be private is very likely to cause harm, and this harm may be rather substantial. (Sending a closed project bid to your competitors, distributing your home phone number to all of d-u's thousands of subscribers, etc.) Sending a reply privately that was intended to go to the list is unlikely to do any more than cause minor annoyance. (Re-send it to the list and you get the original intended effect with no harm done beyond the embarassment of messing it up and the initial recipient seeing it twice.) Granted, for most lists, the substantial majority of replies are intended to go to the list, but the greater degree of harm caused by inadvertently publicizing private information is, I believe, large enough that the average harm-per-reply (i.e., expected harm from a mis-send times the odds of a mis-send) is still lower without setting reply-to. I'm not a list admin here, but that seems to me like a pretty good reason for the current policy. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Is there any security risk using p2p client ?
On Sun, Aug 16, 2009 at 12:05:08PM +0300, ?? wrote: Is that so? The torrent file you download from debian (= you trust that), doesn't contain the checksum? If you're verifying the checksum, then you implicitly don't trust the file 100%. And you shouldn't have 100% trust in any file obtained over the public internet unless solid end-to-end encryption is in place to secure the transfer against man-in-the-middle attacks, DNS-based attacks (which could result in you downloading from a different source than you think you're getting it from), etc. This goes double for any sort of p2p download, since the whole point of p2p downloads is that you're getting small pieces of the file from many different sources, meaning that any one of those sources could potentially have maliciously altered the pieces they're giving you. If you don't trust the file 100%, then why would you trust the checksum it contains? A maliciously-altered file would almost certainly also contain a new checksum which matches the altered version of the file. Always obtain your checksums via an alternate (cryptographically- secured) path, not directly from the data they're being used to verify. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: wi-fi security?
On Wed, Aug 05, 2009 at 12:27:24PM -0500, Boyd Stephen Smith Jr. wrote: However, NO wireless security protocol can protect you from packet sniffing at or *behind* the AP. If the entity that provides the network is a potential attacker, you must use end-to-end security (ssh, ssl, tls, vpn, etc.) for anything not public. IMO, this is the most important point in all discussions of wireless network security. It doesn't matter how secure the wireless connection itself is, the internet at large is (and almost certainly always will be) an untrusted network. If you're already treating all connections across the public internet as untrusted, then it really doesn't matter all that much whether the wireless network you're connected to is trustworthy or not. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How many users will fall for my Disposition-Notification-To?
On Fri, Jun 05, 2009 at 09:00:21AM +0800, jida...@jidanni.org wrote: Fellas, what happens when I put a Disposition-Notification-To: m...@... header at the top of my mail? Yes I know all about the protocol, http://en.wikipedia.org/wiki/Return_receipt#Message_Disposition_Notifications I'm just curious about how many users will fall for my http://en.wikipedia.org/wiki/Web_bug From what I've seen, about half the users' computers I send such a header to send back acknowledgements, and the other half don't. Seems to me you already answered your own question: About half will fall for it. (Not that I have any knowledge of this beyond what you posted, just pointing out that you appear to already have empirical data which answers the question.) -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
ctrl-o (was Re: Rogue Filename - Can't Do A Thing With It)
On Thu, May 21, 2009 at 10:23:13AM -0700, Kelly Clowers wrote: For hard to type file names, I have a line in my .inputrc: Control-o: menu-complete Then you can press ctrl-o repeatedly to cycle through file names. If you can type the beginning of the name, it cycles through only the names that start with whatever you typed. I have found it very useful for some Japanese file names. You might want to map it to a different keystroke, as ctrl-o already does something quite useful by default: When calling up a command from history, ctrl-o executes it and loads the next command in your history into the prompt. e.g., If, at some point in your command history, you did a 'cd' followed by 'ls', you could go back in the history to the 'cd', press ctrl-o, and it would execute the 'cd', then put 'ls' on the command line, ready for you to execute it by just hitting enter (or ctrl-o again, if you want to continue replaying the sequence). It's obviously not that great when you're replaying a sequence of two-character commands, but when you're stepping through a series of longer commands with lots of parameters from way back in the history, it can be a huge convenience. -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Rogue Filename - Can't Do A Thing With It
On Wed, May 20, 2009 at 10:39:38AM -0400, Hal Vaughan wrote: Recently I started getting errors from rsync on a machine I don't tend to have to log on to very often. I checked the bad directory and get this: [...@scarecrow:threshNet]$ ls -l reportX total 0 ?- ? ? ? ?? reportX/2009-r...@? At this point this is the only file in the directory. Originally the directory was report but I changed it to reportX and moved all the other files out of that directory and into the new one (since my rsync cron job only backs up specific directories). If there are more files in that directory, I get just the file names, but this rogue file shows up in the listing with the directory name first -- every time. I've tried this: [...@scarecrow:threshNet]$ rm reportX/* rm: cannot lstat `reportX/2009-raw\...@\037': No such file or directory Sounds to me like you may be dealing with a (hopefully) minor case of filesystem corruption. Have you tried running fsck over that device? (Don't forget to unmount it first!) -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RT3.6 failing mysteriously after lenny upgrade
I finally got around to upgrading from etch to lenny about a week ago and, since then, my Request Tracker installation has been returning blank pages after about 24 hours of operation. An `apache2ctl graceful` will get it working again, but, the next day, I'm right back to blank pages. These white pages were initially associated with a segfault being logged on each request, which gave me something to google for, and I turned up some posts stating that it was likely caused by an incomplete upgrade which did not make all necessary database changes. A specific change was mentioned, which did indeed put an end to the segfaults (it now logs no errors when failing), but the blank pages are still coming back. Some of my google hits mentioned that the change I'd made was not the only one and that you should go through the steps listed in UPGRADING.mysql or re-run upgrade-mysql-schema.pl, but neither of these files appears to exist on my system. (`locate` doesn't find them and `dpkg -L` doesn't list them as being present in the request-tracker3.6 or rt3.6-db-mysql packages.) What do I need to do to recover from this and get RT to stay up 24/7 again? -- Dave Sherohman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Cron - any advanced options?
On Thu, Apr 23, 2009 at 09:29:29AM +0100, Dave Ewart wrote: Don't make it cron's responsibility to check whether the script is already running. Make it the *scripts's* responsibility. Agreed. If you make cron responsible for making sure it doesn't run twice, what happens when someone decides they should (for whatever reason) run it from the command line, a web-based tool, or anything other than cron? For example, the script should create a marker file (or similar) when it runs, deleting the marker file upon completion. Depending on the script, you may also be able to accomplish this with ps instead: ps ax | grep [m]y-script-name If it returns anything, then at least one process named my-script-name is already running, so abort. (The [brackets] around the first letter of my-script-name are to prevent grep my-script-name from appearing in the output and creating a false positive.) -- Dave Sherohman NomadNet, Inc. http://nomadnetinc.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Etch (7.4) - Lenny (8.3) PostgreSQL upgrade issues
I took the plunge and upgraded my server from etch to lenny last night. It went mostly OK, but the PostgreSQL update didn't quite work out... I did see the message during the 8.3 install indicating that manual intervention was required and, per /usr/share/doc/postgresql-8.3/README.Debian.gz, I issued the commands: pg_dropcluster 8.3 main --stop pg_upgradecluster 7.4 main The second command, instead of performing the upgrade, responded with: Error: specified cluster is not running Er, OK... There's still an /etc/init.d/postgresql-7.4, so tell that to start. It returned too quickly for me to believe it had done anything and ps confirmed that no postgres processes were running. Check dpkg --get-selections, and 7.4 is deinstalled. Fine. Tell aptitude to reinstall it. But, alas, No candidate version found for postgresql-7.4. Google has turned up a few discussions in the Debian BTS about whether it would be a good or bad thing to fully-automate the PostgreSQL upgrade process, but nothing that appeared relevant to getting this to work (manually or automatically). So, what do I need to do to recover from this? -- Dave Sherohman NomadNet, Inc. http://nomadnetinc.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Etch (7.4) - Lenny (8.3) PostgreSQL upgrade issues
On Sun, Apr 19, 2009 at 09:53:03PM +1000, CaT wrote: On Sun, Apr 19, 2009 at 05:51:17AM -0500, Dave Sherohman wrote: So, what do I need to do to recover from this? Not had this problem myself but at a guess... put a deb-src line for etch in your sources.list file, then apt-get -b source postgresql-server-7.4 Install all the needed things, then once it's compiled, make a backup of your db, install the resulting debs and follow the procedure you initially tried to follow. Figures I'd miss the obvious... Thanks! That does seem to have taken care of it. -- Dave Sherohman NomadNet, Inc. http://nomadnetinc.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: security (malware) issues in Linux bases OSes
On Sun, Feb 15, 2009 at 04:22:37PM -0300, Eduardo M KALINOWSKI wrote: But neither of these help in case a stupid user receives an e-mail saying: Run 'sudo dpkg -i FreePornPics.deb to see insert celebrity name here's secret sex tape'. No, but it still wouldn't get far because, unlike all the major Windows malware threats, this requires the user to do actual *typing* (eww! yuck!) instead of just going clicky-clicky or auto-running as soon as the message is previewed. -- Dave Sherohman NomadNet, Inc. http://nomadnetinc.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: security (malware) issues in Linux bases OSes
On Mon, Feb 16, 2009 at 07:26:38AM -0700, Paul E Condon wrote: And, without testing it, I'm pretty sure that sudo rm -rf / is trapped and subject to special handling. At least, it should be, IMHO. Only one way to find out whether it is or not... Try it! *evil grin* (Well, OK, you could just look at the source, I suppose, but where's the fun in that?) -- Dave Sherohman NomadNet, Inc. http://nomadnetinc.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] Friday the 13th
On Tue, Feb 10, 2009 at 01:11:06PM -0600, Ron Johnson wrote: Days beginning (near) daybreak, and years beginning on a seasonal boundary and having 13 each 28 day months are also good ideas that won't get implemented. Too much inertia. How would days beginning (near) daybreak cope with extreme latitudes? Vary the lengths of hours so that the day starts at (what we currently call) 1am in the summer and at 3pm in the winter? Or when you get above the arctic circle, where the sun may not rise/set for multiple 24-hour periods? No, I think the much better idea would be to ditch timezones and put the whole world on UTC. Get rid of DST and 12-hour clocks, too, while you're at it. There is absolutely no real benefit to having the clock say 7am when you wake up and 11pm when you go to sleep instead of (assuming UTC-6) waking up at 1:00 (which, remember, represents the same actual time as is currently called 7am in that timezone), working 3-12, and going to bed at 19:00. -- Dave Sherohman NomadNet, Inc. http://nomadnetinc.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] Friday the 13th
On Wed, Feb 11, 2009 at 08:23:25AM -0600, Ron Johnson wrote: On 02/11/2009 05:17 AM, Dave Sherohman wrote: No, I think the much better idea would be to ditch timezones and put the whole world on UTC. Get rid of DST and 12-hour clocks, too, while you're at it. There is absolutely no real benefit to having the clock say 7am when you wake up and 11pm when you go to sleep instead of (assuming UTC-6) waking up at 1:00 (which, remember, represents the same actual time as is currently called 7am in that timezone), working 3-12, and going to bed at 19:00. Of course time zones are a good idea. Humans are still diurnal and like seeing the clock say morning when they wake up after a night's sleep. A clock who's 00:00 is at what is now 06:00 would be coherent with our nature. I believe you have missed my point. There is nothing magical about 00:00 or 06:00 or whatever that makes it morning. It is, IMO, perfectly acceptable for morning to be from 06:00-18:00 in one area and from 18:00-06:00 on the other side of the planet. Switching to a 24-hour clock eliminates any spurious connection to AM being morning and PM being evening, thus allowing morning to be defined based on local conditions rather than tying it to the clock. And yes, DST *is* a good idea in a non-agrarian society, since we all (note the quotes) go to work at the same time. Even though during the summer the Sun rises earlier in the day, we still all go to work at the same time, so that extra amount of daylight in the early morning is wasted, since there's nothing we can do with it. Or, and I realize this is utterly crazy... people could just leave the clock set to the same time and *still go to work an hour earlier, even though the clock says something different*. Once again, there's nothing magical about the numbers on the clock which causes any meaningful change in the world. -- Dave Sherohman NomadNet, Inc. http://nomadnetinc.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
