trying to parse lines from an awkwardly formatted HAR file ...
out of a HAR file containing lots of obfuscating js cr@p and all kinds of
nonsense I was able to extract line looking like:
var00='{\"index\":\"prod-h-006\",\"fields\":{\"identifier\":\"bub_gb_O2EAMAAJ\",\"title\":\"Die
Wissenschaft vom subjectiven Geist\",\"creator\":[\"Karl Rosenkranz\",
\"Mr. ABC123\"],\"collection\":[\"europeanlibraries\",
\"americana\"],\"year\":1843,\"language\":[\"German\"],\"item_size\":797368506},\"_score\":[50.629513]}'
echo "// __ \$var00: |$var00|"
The final result that I need would look like:
var02='bub_gb_O2EAMAAJ|Die Wissenschaft vom subjectiven Geist|["Karl
Rosenkranz", "Mr. ABC123"]|["europeanlibraries",
"americana"]|1843|["German"]|797368506|[50.629513]'
echo "// __ \$var02: |$var02|"
I have tried substring substitution, sed et tr to no avail.
lbrtchx
Re: Root password strength
On Fri, Mar 22, 2024 at 9:02 AM Jan Krapivin wrote:
>
> The thing that bothers me are words: "any computer (and a fortiori any
> server) connected to the Internet is regularly targeted by automated
> connection attempts"
Change it to "any computer (and a fortiori any server) >>using IPv4
and directly<< connected to the Internet is regularly targeted by
automated connection attempts"
and yes, I'm 100% confident they're getting automated connection attempts.
Why the qualifier >>using IPv4 and directly<< connected?
The IPv4 address space is only 32 bits long. Scanning 2^32 = about
4,000,000,000 addresses for an open port is easily doable.
The IPv6 address space is a bit harder... Let's just say that 7/8th
of the IPv6 address space is reserved[1] so that means 2^125 addresses
would need to be scanned .. which just isn't going to happen.
There are ways for attackers to get the IPv6 address scan space down
to a reasonable number. I probably don't know most of them..
What's the difference between "connected" and "directly connected"?
None of my computers are directly connected to the Internet.
Everything is hiding behind a firewall that supposedly blocks _all_
unsolicited traffic coming in from the Internet.
So however much I believe no unsolicited traffic is allowed into my
network is about how much I believe there are no automated connection
attempts to my computers.
> I am not tech-savvy. Can you say with 100% (90%?) confidence that there is no
> such thing? That home PC without SSH and whatever complicated is safe (rather
> safe) from "automated connection attempts"?
What make it more fun is that it is not only SSH that could allow an
attacker in. A quick & easy check is to look for open ports - eg.
sudo ss -lptu
shows you all the programs listening for new connections (right now ..
10 minutes from now could be a whole different thing).
Except.. oops.. not _all_ the programs listening for new connections.
While writing this I tried
$ sudo ss -lwnp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
UNCONN 0 0 0.0.0.0:255 0.0.0.0:*
users:(("atop",pid=186997,fd=4))
so there's atop allowing connections on a "raw" socket. .. whatever that is.
And there's the non-tcp/udp protocols like GRE or IPSec (think VPN
tunnels) where connections might be allowed in.
> This thread reminded of that topic -
> https://forums.debian.net/viewtopic.php?t=154002
Indeed. Is a firewall necessary or no? Some say yes, some say no.
I look at a firewall as the place where you implement your basic
network security policy. Should SSH be allowed in from the Internet?
NetBIOS? how about SNMP?
I fall into the "some say yes" camp because I say the firewall is
where those questions should be answered.
Regards,
Lee
[1]
https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
The assignable Global Unicast Address space is defined in [RFC3513] as
the address block
defined by the prefix 2000::/3. [RFC3513] was later obsoleted by [RFC4291].
Re: THAT obvious troll thread
You would think the email address would be a giveaway . . . jmax@shitposting.expert Cheers Phil On 22/03/2024 11:04 pm, Andy Smith wrote: Slow clap for everyone who replied to THAT obvious troll thread and quoted it for the archives. Your first day on the Internet is it? I had already gone to the trouble of reporting it and Debian postmasters had kindly removed the objectionable post from the web archive, but now in your wisdom you've gone and added it back in by replying to it. With your name attached, for the world to see. Maybe you would like to visit: https://lists.debian.org/debian-user/2024/03/thrd2.html scroll to the bottom, click on the problem emails and use the report as spam button in the top right corner and hope for the best. Next time, please think about it. Thanks, Andy
Anaconda-navigator installation problems
Operating System: Debian GNU/Linux 12 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.0-18-amd64 (64-bit) Graphics Platform: Wayland Processors: 4 × AMD FX(tm)-4350 Quad-Core Processor Memory: 31.2 GiB of RAM Graphics Processor: AMD CAICOS Manufacturer: MSI Product Name: MS-7974 System Version: 1.0 I have been trying to get the Anaconda Navigator to work for a month with no success. I keep getting the following message when trying to start the the program: (base) root@debian:/usr/share/bash-completion/completions# anaconda-navigator 2024-03-21 11:45:36,089 - WARNING linux_scaling.get_scaling_factor_using_dbus:32 An exception occurred during fetching list of system display settings. qt.qpa.xcb: could not connect to display qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized . Reinstalling the application may fix this problem. Available platform plugins are: eglfs, minimal, minimalegl, offscreen, vnc, webgl, xcb. Aborted (core dumped) Any help will be sincerely appreciated. Gary R.
Re: debian-niggers and debian-lgbt projects.
On Fri, 2024-03-22 at 20:39 +, Terence wrote: > No, starting any Debian linked group (i.e. using Debian any form) based on personal differentiation is totally unacceptable. To do so is to encourage division between a world wide, extremely diverse group of users of our computer operating system, for racial, ethnic, age, sexual, or or any other attribute. The internet is neutral, although it is used for all sorts of divisive and offensive uses, and we can keep it so in the Debian world of ours if we wish. > In all my years (decades now) use of Debian I have communicated all over the world with Debian users, and have not cared or needed to know anything more than that I was dealing with another Debian enthusiast. > Perhaps it would be interesting to hear the original poster's views on whether proposals to form a "debian-gay-beaters", "debian-hetrosexuals" or a "debian-white-supremacists" group would meet with his/her/it's approval. > > I am against all attempts to promote division between people, either collectively or individually, even down to deploring the antagonism (from mild to violent) between supporters of different sports teams. If they were really sports enthusiasts they would applaud good play, even when it was not to their own teams advantage. > > To start, or accept, special interests groups attached to the name "Debian" in any form is to be resisted by all means possible. Agreed! An inane proposal. How does anybody's suntan, sexual preference, or any other attribute bear on their use of an operating system? We are already differentiated enough: we are Debian users. Cheers! > > On Fri, 22 Mar 2024 at 16:12, Zenaan Harkness <[zen...@gmail.com](mailto:zen...@gmail.com)> wrote: > > > > On Fri, Mar 22, 2024 at 6:02 PM Paul M Foster <[pa...@quillandmouse.com](mailto:pa...@quillandmouse.com)> wrote: > > > > > On Thu, Mar 21, 2024 at 06:47:10PM +, jmax wrote: > > > > > > > Dear Brothers and Sisters: > > > > > > > > I am interested in starting some debian projects. As a homosexual, > > > > debian-using, black, I am surprised at the low numbers of black and/or LGBT > > > > members of the debian community. I believe that starting debian-niggers, and > > > > debian-gay or debian-lgbt projects would help to increase participation of > > > > the respective parties in the debian community. > > > > > > I'm not your brother or sister, and not part of your demographic, and I > > > really don't care whether you do or don't start a SIG on black or LGBT > > > Debian interests. > > > > > > However, the word "nigger" is plainly offensive. It's been offensive for > > > decades, and most recently, whites have been entirely prohibited from > > > using the word, upon pain of death, while blacks readily use it with > > > impunity. > > > > > > If you're going to start a SIG for black/LGBT Debianistas, I'd politely > > > request you do so without resorting to inflammatory language. I imagine the > > > term "debian-blacks" would serve just as well without aggravating an already > > > strongly divided world. > > > > Yeah I'd probably be ok with debian-blacks, but someone will probably complain. I think it could be good for the community if it did come true. > > > > > > > In fact, I suspect the less we pay attention to skin color, the better off > > > we all will be. > > > > Sadly we have no choice on this these days. We probably also have to create debian-yellows now, and while we're at it, debian-rainbow or debian-pride might be more politically correct. > > > > It's difficult to come up with names sometimes, but I'm sure we're up to the job. > >
Re: Debian 12.5.0 amd64 and OpenZFS bug #15526
> On 27 Feb 2024, at 23:47, Gareth Evans wrote: > On Tue 27/02/2024 at 22:52, David Christensen > wrote: >> ... >> These appear to be the ZFS packages for the available Debian releases: >> >> https://packages.debian.org/buster/zfs-dkms >> >> busterzfs-dkms (0.7.12-2+deb10u2) >> buster-backportszfs-dkms (2.0.3-9~bpo10+1) >> bullseyezfs-dkms (2.0.3-9+deb11u1) >> bullseye-backportszfs-dkms (2.1.11-1~bpo11+1) >> bookwormzfs-dkms (2.1.11-1) >> bookworm-backportszfs-dkms (2.2.2-4~bpo12+1) >> trixiezfs-dkms (2.2.2-4) >> >> >> The question is, how far back to go? Is OpenZFS 2.1.x buggy? OpenZFS >> 2.0.x? What is 0.7.12 -- OpenZFS, ZFS-on-Linux, or something else -- >> and is it buggy? > > This seems to be very "involved"! The discussion in #15526 suggests a > coreutils upgrade (particularly re. "cp") in combination with the addition of > the zpool block cloning feature seems to have triggered the issue, which may > have gone undetected for some time. > >>> After downgrading coreutils from 9.3 to 8.32, I am no longer able to >>> reproduce this corruption. >> This seems to solve the corruption issue on my end too. > -- https://github.com/openzfs/zfs/issues/15526#issuecomment-1810472547 > > See also > https://www.reddit.com/r/zfs/comments/1826lgs/psa_its_not_block_cloning_its_a_data_corruption/ > > Debian users can't follow the gentoo/emerge-based reproduction/trigger steps > for build of golang in > https://github.com/openzfs/zfs/issues/15526 (for zfs 2.2.0) > and > https://github.com/openzfs/zfs/issues/15933 (for 2.2.3) > > If anyone can recommend steps to debianise these (15933 seem most likely to > be useful, and slightly different), I would be happy to test openzfs 2.2.2-4 > from bookworm-backports on deb 12.5 > > Given that the original gentoo reporter, who seems to have tested > extensively, considered the issue closed after upgrade to openzfs 2.2.2 > > https://bugs.gentoo.org/917224#c26 > > I wonder if the 2.2.3 issue is similar/related, or perhaps there are multiple > triggers. > > Watching with interest. > > Best wishes, > Gareth > As anyone interested can see from the ref to #15933 in the below, there seems to have been considerable effort in getting to grips with this bug (actually multiple bugs), and it looks like a fix may be forthcoming, though not sure at the time of writing if there may be some further polishing first https://github.com/openzfs/zfs/pull/16019
Re: debian-niggers and debian-lgbt projects.
No, starting any Debian linked group (i.e. using Debian any form) based on personal differentiation is totally unacceptable. To do so is to encourage division between a world wide, extremely diverse group of users of our computer operating system, for racial, ethnic, age, sexual, or or any other attribute. The internet is neutral, although it is used for all sorts of divisive and offensive uses, and we can keep it so in the Debian world of ours if we wish. In all my years (decades now) use of Debian I have communicated all over the world with Debian users, and have not cared or needed to know anything more than that I was dealing with another Debian enthusiast. Perhaps it would be interesting to hear the original poster's views on whether proposals to form a "debian-gay-beaters", "debian-hetrosexuals" or a "debian-white-supremacists" group would meet with his/her/it's approval. I am against all attempts to promote division between people, either collectively or individually, even down to deploring the antagonism (from mild to violent) between supporters of different sports teams. If they were really sports enthusiasts they would applaud good play, even when it was not to their own teams advantage. To start, or accept, special interests groups attached to the name "Debian" in any form is to be resisted by all means possible. On Fri, 22 Mar 2024 at 16:12, Zenaan Harkness wrote: > > On Fri, Mar 22, 2024 at 6:02 PM Paul M Foster > wrote: > >> On Thu, Mar 21, 2024 at 06:47:10PM +, jmax wrote: >> >> > Dear Brothers and Sisters: >> > >> > I am interested in starting some debian projects. As a homosexual, >> > debian-using, black, I am surprised at the low numbers of black and/or >> LGBT >> > members of the debian community. I believe that starting >> debian-niggers, and >> > debian-gay or debian-lgbt projects would help to increase participation >> of >> > the respective parties in the debian community. >> >> I'm not your brother or sister, and not part of your demographic, and I >> really don't care whether you do or don't start a SIG on black or LGBT >> Debian interests. >> >> However, the word "nigger" is plainly offensive. It's been offensive for >> decades, and most recently, whites have been entirely prohibited from >> using the word, upon pain of death, while blacks readily use it with >> impunity. >> >> If you're going to start a SIG for black/LGBT Debianistas, I'd politely >> request you do so without resorting to inflammatory language. I imagine >> the >> term "debian-blacks" would serve just as well without aggravating an >> already >> strongly divided world. >> > > Yeah I'd probably be ok with debian-blacks, but someone will probably > complain. I think it could be good for the community if it did come true. > > >> In fact, I suspect the less we pay attention to skin color, the better off >> we all will be. >> > > Sadly we have no choice on this these days. We probably also have to > create debian-yellows now, and while we're at it, debian-rainbow or > debian-pride might be more politically correct. > > It's difficult to come up with names sometimes, but I'm sure we're up to > the job. >
Re: Client ''frozen'' dans un environnement avec un serveur LTSP
Bonsoir à tous, Le problème est connu depuis 2008 comme vous pourrez le constater en cliquant sur le lien ci-dessous : https://forum.ubuntu-fr.org/viewtopic.php?id=261646 Bonne soirée ! Le 2024-03-20 16:32, Alex PADOLY a écrit : Bonsoir à tous, J'ai mis en place un réseau dans lequel il y a un serveur LTSP fonctionnant sous DEBIAN. Aucun problème concernant la configuration du serveur. Je n'arrive toujours pas à comprendre pourquoi, après le démarrage du client, celui-ci se fige au déplacement de la souris ou à l'utilisation du clavier. J'ai fait des recherches sur Internet, il y a des personnes qui ont rencontré la même situation, mais je n'ai pas réussi à avoir une explication rigoureuse. Si certains d'entre vous ont été confrontés à la même situation, merci de faire part de vos impressions… moi j'ai envie de fouiller au niveau du serveur X et/ou faire des essais avec un clavier PS/2 et une souris PS/2. Cordialement. Alex PADOLY
Re: Redis license change
Hi, On Fri, Mar 22, 2024 at 07:00:40AM +0100, Micke Nordin wrote: > What will Debian do with regard to the Redis announcement that > they will go proprietary[0]? There isn't really any choice as it's no longer free software. So at best it gets moved into non-free I suppose (it is still source available) if anyone has the will. It seems likely that the maintainer will not have the will to see it moved to non-free. You'd have to ask them. As for what if anything replaces it, it is more down to if anyone has the will and interest to package things. I expect there'll be some alternatives packaged, since it's a popular use case. > Fedora seems to be moving fast to get rid of Redis[1] and maybe we > should start thinking about this too? It won't require much thinking. It's not a matter for debate whether it qualifies for the main archive - it doesn't. > Redict is a very new project, and a direct result of the license > change. The KeyDB project have been a round for a while and is in > heavy use by Snapchat, but does not see a heavy invetment in time > from them, so development is quite slow. When it comes to Debian it's more about will anyone put in the work. There is no central authority saying, "the project needs to replace Redis. Let us select XYZ as its replacement." — as there might be in, say, Fedora, where FESCo would make decisions like that. Debian doesn't work that way. There is no barrier to both KeyDB and Redict being packaged, other than there being maintainers to do it. You may like to submit a Request For Packaging bug for one or both, though again, may not get very far unless someone is already interested in doing it. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Root password strength
On 22.03.2024 14:57, Jan Krapivin wrote: чт, 21 мар. 2024 г. в 22:34, Alexander V. Makartsev : This conclusion seems less than optimal to me. By condemning yourself to type 12+ character password every time you 'sudo' would really hurt accessibility and usability of your home computer and for no good reason. If we focus solely on your use case: a login security of a PC at home, without remote access, then password of your sudo user could be as short and simple as four numbers, of course unrelated to your date of birth, phone number, or any other easily guessable sequence of numbers, like '1234'. Are you speaking only about sudo or root password also? Dealing with root password could be tricky and you have three options: 1. You can implement the same 'faillock' scheme for root user as well and make root password shorter for convenience. Pro: 3 failed login attempts and root user will be locked for a time period. Con: You or somebody can (un)intentionally lock out root user for a time period. 2. You can set good password (12+ symbols) for root user without 'faillock' scheme. Pro: You will be always able to login as root user. Con: Typing 12+ symbols password could be a headache. 3. You can unset (delete) root user password and lock the account. Pro: Nobody will be able to login as root user directly. Instead you will have to rely on sudo user to gain root privileges. Con: You will have to keep sudo account safe and set shorter lockup time period or make another sudo user as backup. If you prefer to have root user as failsafe, to fix system when you screw something up. I suggest to go for option 2 and keep it simple. The thing that bothers me are words: "*_any_* computer (and a fortiori any server) connected to the Internet*_is regularly targeted by automated connection attempts" _* I am not tech-savvy. Can you say with 100% (90%?) confidence that there is no such thing? That home PC without SSH and whatever complicated is safe (rather safe) from "*_automated connection attempts"? _* This thread reminded of that topic - https://forums.debian.net/viewtopic.php?t=154002 *_ _* That statement is not entirely true, because it depends on a method how a PC is connected to the Internet. There are three options: 1. Your PC is connected to Local Area Network (LAN) and there is a router/firewall device between your PC and the Internet cord. In this case any unsolicited Internet traffic (automated connections, port scans, etc) will be stopped by router/firewall device. This is because of how IPv4 network address translation (NAT) works, to allow multiple LAN hosts to connect to Internet with single IP address assigned by Internet Service Provider (ISP). In case you would want some traffic to reach your PC through a router/firewall device, you will have to configure a rule and allow it on router/firewall device. 2. Your PC is connected to a router device that works as a network bridge and your PC has public IP address assigned by ISP. In this case any unsolicited Internet traffic (automated connections, port scans, etc) will reach your PC and should be stopped by a firewall. 3. Your PC is connected to Internet cord directly and PC has public IP address assigned by ISP. In this case any unsolicited Internet traffic (automated connections, port scans, etc) will reach your PC and should be stopped by a firewall. In cases 2 and 3 you have to keep firewall up and configured to block incoming traffic. Also you have to be aware of any active network services on your PC that could be accessed from the Internet and it is your job to keep them secure. These services could be anything: SSH server, FTP server, HTTP server, SQL server, SAMBA server, game servers, etc. In case 1 you are relatively safe from Internet traffic noise. Hosts on your LAN are separated from the Internet by router/firewall device. Now, I don't want to scaremonger and feed anyone's paranoia, but for the sake of completion, there are known cases in history when router/firewall had vulnerabilities, or firmware flaws, or configuration negligence, that allowed perpetrators to 'hack' them, as in gain full access and control over their firmware and gain network access to LAN hosts. These cases are extremely rare nowadays and very hard to pull off successfully, especially if the device owner keeps firmware up-to-date and configuration tidy. I hope this helps you to understand a little more how networking works under the hood and while there is indeed a network traffic noise reaching every second every host on the Internet, 99.99% of it simply dropped by firewalls, ISP filters, or fail otherwise. -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
THAT obvious troll thread
Slow clap for everyone who replied to THAT obvious troll thread and quoted it for the archives. Your first day on the Internet is it? I had already gone to the trouble of reporting it and Debian postmasters had kindly removed the objectionable post from the web archive, but now in your wisdom you've gone and added it back in by replying to it. With your name attached, for the world to see. Maybe you would like to visit: https://lists.debian.org/debian-user/2024/03/thrd2.html scroll to the bottom, click on the problem emails and use the report as spam button in the top right corner and hope for the best. Next time, please think about it. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Root password strength
On Fri, 22 Mar 2024 12:57:20 +0300 Jan Krapivin wrote: > чт, 21 мар. 2024 г. в 22:34, Alexander V. Makartsev > : > > > This conclusion seems less than optimal to me. > > By condemning yourself to type 12+ character password every time you > > 'sudo' would really hurt accessibility and usability of your home > > computer and for no good reason. > > > > If we focus solely on your use case: a login security of a PC at > > home, without remote access, then password of your sudo user could > > be as short and simple as four numbers, of course unrelated to your > > date of birth, phone number, or any other easily guessable sequence > > of numbers, like '1234'. > > Are you speaking only about sudo or root password also? > > The thing that bothers me are words: "*any* computer (and a fortiori > any server) connected to the Internet > > * is regularly targeted by automated connection attempts"* > I am not tech-savvy. Can you say with 100% (90%?) confidence that > there is no such thing? That home PC without SSH and whatever > complicated is safe (rather safe) from " > > *automated connection attempts"?* > This thread reminded of that topic - > https://forums.debian.net/viewtopic.php?t=154002 Most people connect to the Net through a router, usually supplied by the ISP. By default, that router should not permit any connection attempts. It is worth checking its configuration, in case some 'helpful' supplier has enabled uPnP 'to make it easier to play online games'. If so, turn it off. Make sure router management is not permitted from the WAN side. Some ISPs expect to be able to access the router from the Net, something which should be discouraged. If you haven't already, change the admin password from the default, though you probably won't be able to change the account name. If you use wi-fi, then use the best security your router and clients can deal with, usually WPA2. If you don't use wi-fi, turn it off at the router. Really, with a router in its factory default condition, nothing from outside should ever get as far as your computer. The problems don't usually start until you want to run some kind of server software which is accessible from outside, which must then be appropriately secured. The main security issues, of course, come from connections you have invited into your computer, malicious email and web pages. All you can do to mitigate those threats is to be sensible and careful. -- Joe
Re: debian-niggers and debian-lgbt projects.
On Fri, Mar 22, 2024 at 6:02 PM Paul M Foster wrote: > On Thu, Mar 21, 2024 at 06:47:10PM +, jmax wrote: > > > Dear Brothers and Sisters: > > > > I am interested in starting some debian projects. As a homosexual, > > debian-using, black, I am surprised at the low numbers of black and/or > LGBT > > members of the debian community. I believe that starting debian-niggers, > and > > debian-gay or debian-lgbt projects would help to increase participation > of > > the respective parties in the debian community. > > I'm not your brother or sister, and not part of your demographic, and I > really don't care whether you do or don't start a SIG on black or LGBT > Debian interests. > > However, the word "nigger" is plainly offensive. It's been offensive for > decades, and most recently, whites have been entirely prohibited from > using the word, upon pain of death, while blacks readily use it with > impunity. > > If you're going to start a SIG for black/LGBT Debianistas, I'd politely > request you do so without resorting to inflammatory language. I imagine the > term "debian-blacks" would serve just as well without aggravating an > already > strongly divided world. > Yeah I'd probably be ok with debian-blacks, but someone will probably complain. I think it could be good for the community if it did come true. > In fact, I suspect the less we pay attention to skin color, the better off > we all will be. > Sadly we have no choice on this these days. We probably also have to create debian-yellows now, and while we're at it, debian-rainbow or debian-pride might be more politically correct. It's difficult to come up with names sometimes, but I'm sure we're up to the job.
Re: Root password strength
чт, 21 мар. 2024 г. в 22:34, Alexander V. Makartsev : > This conclusion seems less than optimal to me. > By condemning yourself to type 12+ character password every time you > 'sudo' would really hurt accessibility and usability of your home computer > and for no good reason. > > If we focus solely on your use case: a login security of a PC at home, > without remote access, then password of your sudo user could be as short and > simple as four numbers, of course unrelated to your date of birth, phone > number, or any other easily guessable sequence of numbers, like '1234'. > Are you speaking only about sudo or root password also? The thing that bothers me are words: "*any* computer (and a fortiori any server) connected to the Internet * is regularly targeted by automated connection attempts"* I am not tech-savvy. Can you say with 100% (90%?) confidence that there is no such thing? That home PC without SSH and whatever complicated is safe (rather safe) from " *automated connection attempts"?* This thread reminded of that topic - https://forums.debian.net/viewtopic.php?t=154002
Re: Can't find informatin on passwdqc, pwqcheck or cracklib
On Fri March. 22, 2024, at 03:39, NC wrote: > I'm wanting to upgrade my security, and like to use some of the > suggested tools. I've installed some of the tools, but can't find man > pages on them. Similarly there's no results to be had from googling. > I must be missing something.. > As far as I can tell, passwdqc package installs man pages for pwqcheck pwqfilter pwqgen Loïc
Spotkanie w sprawie nowej aplikacji
Dzień dobry, chciałabym dotrzeć do osoby odpowiedzialnej lub decyzyjnej w obszarze zarządzania dokumentacją w Państwa firmie. Zapewniamy możliwość innowacyjnego, elektronicznego obiegu dokumentacji opartego na wykorzystaniu nowoczesnej aplikacji no-code, która działa wielowymiarowo i automatyzuje procesy biznesowe oraz operacyjne. Wykorzystanie aplikacji wpływa na optymalizację procesów, m.in zarządzanie łańcuchem dostaw, kontrola sprzedaży i eksport faktur kosztowych. Dodatkowo umożliwia generowanie zamówień i błyskawiczne ich powiązanie z fakturami oraz dokumentami PZ. Z powodzeniem realizowaliśmy wdrożenia dla wielu dużych przedsiębiorstw, takich jak: Carrefour, Lafarge, Medicover i CCC. Czy możemy porozmawiać o obiegu dokumentacji w Państwa firmie? Pozdrawiam Monika Barnaś
Re: Can't find informatin on passwdqc, pwqcheck or cracklib
On 22 Mar 2024 13:16 +1100, from n...@linearg.com: > I'm wanting to upgrade my security, and like to use some of the suggested > tools. I've installed some of the tools, but can't find man pages on them. You can see the files installed by a package by running: $ dpkg -L For example: $ dpkg -L coreutils man pages will typically be under /usr/share/man: $ dpkg -L coreutils | grep ^/usr/share/man/ dpkg -L == dpkg --listfiles Note that this will not list files generated during installation (for example a kernel module package that triggers a DKMS build would likely show the source code but _not_ the built binaries) or configuration files created later; but that shouldn't be an issue with man pages. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Redis license change
What will Debian do with regard to the Redis announcement that they will go proprietary[0]? Fedora seems to be moving fast to get rid of Redis[1] and maybe we should start thinking about this too? Some drop in replacements are KeyDB[2] and redict[3]. Both of these have issues as far as debian packaging goes. KeyDB haven't yet synched the 7.x changes from upstream redis, and are still on the 6.3 patch level. Redict is a very new project, and a direct result of the license change. The KeyDB project have been a round for a while and is in heavy use by Snapchat, but does not see a heavy invetment in time from them, so development is quite slow. 0. https://redis.com/blog/redis-adopts-dual-source-available-licensing 1. https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/XVFFKU2NYB2Q3BQUYNANSDNE4VCJQ6KF 2. https://github.com/Snapchat/KeyDB/issues/798 3. https://codeberg.org/redict/redict All the best, Micke
