[gentoo-user] Re: 2 months into an 8-month computation.
On 11/07/2019 20:59, Alan Grimes wrote:
'ey, I have the 2.3 months into an 8-month computation blues...
[...]
So basically all gentoo updates will have to be done at the end of this
run, I'm not really sure when, sometime in the December-January timeframe.
I guess you should have written your code in a way that can store
current state so that it can resume. Failing that, you could have used a
VM that can save ("suspend") the guest state so that you can resume later.
Food for thought for the future, I guess :-)
[gentoo-user] Re: conditional sysctl tweaks?
On 11/07/2019 20:03, Ian Zimmerman wrote: What is the cleanest way to handle the situation when a new sysctl knob is introduced by a kernel release and I want to use it, but I also have older kernels around? What's the point of that?
Re: [gentoo-user] Re: escape from i3lock
> So the solution is to just use "xscreensaver" by jwz. Which can be > configured to just blank the screen etc. as wanted by the op. See > also > the FAQ: https://www.jwz.org/xscreensaver/faq.html > > HTH, > -dnh > Except I use xscreensaver myself and it in no way prevents VT switch, which is what the OP was hoping to find a way to do if and only if the screen is locked. Programs that grab input still don't get to block combos that are processed by the X server before they even get to the program's input queue any more than grabbing input will block the alt- sysrq kernel-level interrupt keys. Disabling VT switch by the X server and then setting up some other way to trigger a switch that will be blocked by whatever screen locking program the OP wishes to use is the best solution I can think of. chvt would be the program to call. Whether he wants it to be a keyboard shortcut handled by his DE or some other trigger method is a matter of taste. LMP signature.asc Description: This is a digitally signed message part
Re: [gentoo-user] Re: escape from i3lock
Hello, On Thu, 11 Jul 2019, Laurence Perkins wrote: >You could also leave DontVTSwitch on all the time and set a keyboard >shortcut to run chvt (man 1 chvt) with appropriate permissions and >parameters instead. Keyboard shortcuts shouldn't get processed if the >screen is locked. The screensaver has to get _and keep_ the lock on input. The sad thing is, people do needless rewrites and get it wrong again and again and again, despite jwz' xscreensaver code from 1991 on, setting an example on how to do it right... Cue gnome-screensaver, the kde stuff, apparently also i3lock etc.pp. ad nauseam, all repeating the very bugs jwz wrote about in 2004 (the toolkits.html)... VT Switching is just a little subclass of the underlying problems of those "lock screen" programs that don't lock your screen. https://www.jwz.org/xscreensaver/toolkits.html / Epilogue I wrote this document in 2004, explaining the approach to privilege separation that xscreensaver has taken since 1991. Of course, the people doing needless rewrites of xscreensaver have ignored it for that whole time, and have then gone on to introduce exactly the bug that I described in this document as a hypothetical strawman! And -- this would be hilarious if it weren't so sad -- have introduced it multiple times. As I said in 2015: If you are not running xscreensaver on Linux, then it is safe to assume that your screen does not lock. Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. (read the whole thing linked document!). Also: https://www.jwz.org/xscreensaver/man1.html#8 https://www.jwz.org/blog/2014/04/the-awful-thing-about-getting-it-right-the-first-time-is-that-nobody-realizes-how-hard-it-was/ https://www.jwz.org/blog/2015/04/i-told-you-so-again/ (also follow the "previous" links ;) So the solution is to just use "xscreensaver" by jwz. Which can be configured to just blank the screen etc. as wanted by the op. See also the FAQ: https://www.jwz.org/xscreensaver/faq.html HTH, -dnh -- "Humans need fantasy .. to *be* human" -- Death (in Hogfather)
Re: [gentoo-user] strange problem (no video output) on new PC
On Thursday, 11 July 2019 23:31:51 BST Jack wrote: > I'm hoping the cumulative wisdom of the assembled masses might be able > to figure out what I'm clearly missing, assuming there IS something I'm > missing. > > I've recently assembled a new PC, with an MSI B350-Tomahawk motherboard > and a Ryzen 5 2600 CPU. (We'll skip that I ended up actually buying an > older Ryzen just to upgrade the BIOS.) The problem is that I have now > tried three different PCI-E graphics cards, and have gotten no video > signal from any of them. I do get a video signal from an ancient PCI > graphics card. One of the cards is a very old Radeon, one is a > slightly less old nVidia, and the newest is (from lspci) "Advanced > Micro Devices, Inc. [AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 > 250X]." > > What I find particularly odd is that if I log in blind, and then issue > startx, X (startkde) seems to be running fine. I ssh in from another > PC, and the X log shows the Radeon driver loading, the monitor being > recognized on the appropriate connector, the EDID received, and the > right resolution being chosen. (Even without all the AMD drivers and > firmware loaded, at least it also seemed to start with the VESA driver, > but still no output signal.) > > I can easily believe the old radeon card is dead, and possibly even the > nVidia card. However, given what I see in the logs with the new radeon > card, I find it hard to believe the card is actually defective. (Just > purchased used on eBay, so I do have to admit the possibilty.) > However, I have trouble imagining what else could be the problem. I've > tried two different cables (both of which work fine for the PCI card) > but both use DVI to VGA adaptors, although I can't imagine why that > would matter now, if they worked for a different card. I have ordered > a new DVI cable to go directly from the card to the monitor, so > hopefully I'll get that and be able to test it within a few days. > > Can anyone else thing of what the problem might be, and if there is any > troubleshooting I could try? > > Jack Brief response for now: If dmesg after you login remotely shows the graphics card firmware is available in the kernel, radeon/nvidia drivers are loading and no errors are printed, then hardware wise your PC ought to be OK. If /var/log/Xorg.0.log shows no errors with drivers and monitor, then I don't know what to suggest other than following a process of elimination, by trying: - different cables - different monitor However, if cables or monitor were at fault I would expect warnings to show up in the log files. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] strange problem (no video output) on new PC
I'm hoping the cumulative wisdom of the assembled masses might be able to figure out what I'm clearly missing, assuming there IS something I'm missing. I've recently assembled a new PC, with an MSI B350-Tomahawk motherboard and a Ryzen 5 2600 CPU. (We'll skip that I ended up actually buying an older Ryzen just to upgrade the BIOS.) The problem is that I have now tried three different PCI-E graphics cards, and have gotten no video signal from any of them. I do get a video signal from an ancient PCI graphics card. One of the cards is a very old Radeon, one is a slightly less old nVidia, and the newest is (from lspci) "Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 250X]." What I find particularly odd is that if I log in blind, and then issue startx, X (startkde) seems to be running fine. I ssh in from another PC, and the X log shows the Radeon driver loading, the monitor being recognized on the appropriate connector, the EDID received, and the right resolution being chosen. (Even without all the AMD drivers and firmware loaded, at least it also seemed to start with the VESA driver, but still no output signal.) I can easily believe the old radeon card is dead, and possibly even the nVidia card. However, given what I see in the logs with the new radeon card, I find it hard to believe the card is actually defective. (Just purchased used on eBay, so I do have to admit the possibilty.) However, I have trouble imagining what else could be the problem. I've tried two different cables (both of which work fine for the PCI card) but both use DVI to VGA adaptors, although I can't imagine why that would matter now, if they worked for a different card. I have ordered a new DVI cable to go directly from the card to the monitor, so hopefully I'll get that and be able to test it within a few days. Can anyone else thing of what the problem might be, and if there is any troubleshooting I could try? Jack
Re: [gentoo-user] Re: escape from i3lock
You could also leave DontVTSwitch on all the time and set a keyboard shortcut to run chvt (man 1 chvt) with appropriate permissions and parameters instead. Keyboard shortcuts shouldn't get processed if the screen is locked. LMP On Thu, 2019-07-11 at 21:01 +, artur.tamm...@gmail.com wrote: > I tried to google if it is possible to change xorg serverflags in > runtime, > but was unable to find anything. I think that would be a cleaner > solution > (changing the DontVTSwitch option before locking and then restoring > later). > > Artur > > Ian Zimmerman writes: > > > On 2019-07-11 09:57, Ian Zimmerman wrote: > > > > > > setxkbmap -option srvrkeys:none > > > > i3lock -c 003355 -n > > > > setxkbmap -option '' > > > > > > Thanks for the idea! It won't work as is for me because I > > > already use > > > some non-default xkb options. But it is closer than anything > > > that has > > > come up yet. I'll get there. > > > > Okay, I got it to work in a brute force way: I just added another > > setxkbmap command to set my normal options, the same ones as in my > > xorg.conf. > > > > But something weird happens when I try the fancy way: saving the > > options > > with "setxkbmap -print >FILE" and then restoring them with "xkbcomp > > FILE". It seems that the change I make with "setxkbmap -option > > FOO" is > > never reflected in the output of "setxkbmap -print". > > > > Looks like another place with multiple "levels" of configuration > > stepping over each other. > > > > -- > > Please don't Cc: me privately on mailing lists and Usenet, > > if you also post the followup to the list or newsgroup. > > To reply privately _only_ on Usenet and on broken lists > > which rewrite From, fetch the TXT record for no-use.mooo.com. > > signature.asc Description: This is a digitally signed message part
[gentoo-user] Re: escape from i3lock
I tried to google if it is possible to change xorg serverflags in runtime, but was unable to find anything. I think that would be a cleaner solution (changing the DontVTSwitch option before locking and then restoring later). Artur Ian Zimmerman writes: On 2019-07-11 09:57, Ian Zimmerman wrote: > > setxkbmap -option srvrkeys:none > > i3lock -c 003355 -n > > setxkbmap -option '' > > Thanks for the idea! It won't work as is for me because I already use > some non-default xkb options. But it is closer than anything that has > come up yet. I'll get there. Okay, I got it to work in a brute force way: I just added another setxkbmap command to set my normal options, the same ones as in my xorg.conf. But something weird happens when I try the fancy way: saving the options with "setxkbmap -print >FILE" and then restoring them with "xkbcomp FILE". It seems that the change I make with "setxkbmap -option FOO" is never reflected in the output of "setxkbmap -print". Looks like another place with multiple "levels" of configuration stepping over each other. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: escape from i3lock
On 2019-07-11 09:57, Ian Zimmerman wrote: > > setxkbmap -option srvrkeys:none > > i3lock -c 003355 -n > > setxkbmap -option '' > > Thanks for the idea! It won't work as is for me because I already use > some non-default xkb options. But it is closer than anything that has > come up yet. I'll get there. Okay, I got it to work in a brute force way: I just added another setxkbmap command to set my normal options, the same ones as in my xorg.conf. But something weird happens when I try the fancy way: saving the options with "setxkbmap -print >FILE" and then restoring them with "xkbcomp FILE". It seems that the change I make with "setxkbmap -option FOO" is never reflected in the output of "setxkbmap -print". Looks like another place with multiple "levels" of configuration stepping over each other. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: escape from i3lock
On 2019-07-10, François-Xavier CARTON wrote: > On 7/10/19 7:03 PM, Ian Zimmerman wrote: >> Here is my next "low information" question, haha. >> >> I use i3lock which is like Xscreensaver but much much simpler; it plays >> no movies or games, just blanks the screen with a configured color or >> image. To unlock it you have to type your password. >> >> It bothers me that even when i3lock has locked the X session, I can >> still switch to other Linux virtual consoles with Alt-Control-F , >> without typing the password. It so happens that on one of the other >> virtual consoles there is often an interactive root shell :-P >> >> So, is it possible to prevent virtual console switching while the X >> screen is locked, but still allow it at other times? Looks like >> something the locker program would have to do, not the X server; but >> again I don't know much about this stuff. >> > > Not a direct answer to your question, but as a workaround you can use > tmux sessions, and simply detach them and logout when you lock your > computer. > > Also, if this is just a shell to start the X server, you can launch it > as "startx & bg; disown" and then logout. > Another workaround: If you can't find a better solution, give vlock a try: vlock -n -a -- Nuno Silva
Re: [gentoo-user] Decent single-user/embedded-device security standard
>You could still use USGCB (or which ever standard the auditors regard highly) >but then document the differences with a >note explaining why. For USGCB I'd add another column to the spreadsheet with >options of compliant/non compliant with >mitigations/non compliant/not applicable and another column for notes. eg >umask 077 would be compliant, and in the >notes column "stricter than required". > >From their point of view they need to justify passing you, and USGCB states >"these recommendations do not address >site-specific configuration issues. Care must be taken when implementing these >settings to address local operational >and policy concerns" so deltas are expected. Don't worry if it seems like its >all deltas... Yeah, that was the fallback option. I was just hoping there was something in reasonably common usage that wouldn't end up being 60% deltas and didn't look like it was compiled by a practitioner of voodoo instead of someone who actually understands how the system works. From: Adam Carter Sent: Wednesday, July 10, 2019 5:27:55 PM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Decent single-user/embedded-device security standard On Thu, Jul 11, 2019 at 9:30 AM Laurence Perkins mailto:lperk...@openeye.net>> wrote: When the security auditors come through and ask what standard I use for securing my systems I'd like to have something to tell them. I've had a few suggestions like USGCB, etc. But looking at them they all seem to start from the direction of "take a bloated, wide-open Microsoft/Redhat default OS and do these things to make it 'secure' so you can let several dozen users play around on it without fear." A lot of the stuff on the list doesn't apply to or would slightly reduce the overall security of the device (I think I'll keep my default umask at 077 thanks...) You could still use USGCB (or which ever standard the auditors regard highly) but then document the differences with a note explaining why. For USGCB I'd add another column to the spreadsheet with options of compliant/non compliant with mitigations/non compliant/not applicable and another column for notes. eg umask 077 would be compliant, and in the notes column "stricter than required". >From their point of view they need to justify passing you, and USGCB states >"these recommendations do not address site-specific configuration issues. Care >must be taken when implementing these settings to address local operational >and policy concerns" so deltas are expected. Don't worry if it seems like its >all deltas...
[gentoo-user] 2 months into an 8-month computation.
'ey, I have the 2.3 months into an 8-month computation blues... I stupidly fired up my number theory code which grows at roughly 3^x (where X = 49 right now...). (current position in the search space: 0x149b87d9 ) 0 hits so far, the set I'm looking for is incredibly sparse... My code is posted here: https://github.com/AlonzoTG/palindromes23 Here's the known examples of the set I'm working on: https://github.com/AlonzoTG/palindromes23/blob/master/numbers Basically I have nothing better to do with my life than run this code. =\ My 360mm rad is sucessfully keeping my 1800x stable at 3842mhz, 25gb of ram is allocated to the process... (uptime = 75 days) (15 process threads running...) So basically all gentoo updates will have to be done at the end of this run, I'm not really sure when, sometime in the December-January timeframe. I just want to warn you that I will be expressing rage and fury if my old, much maligned update scripts don't work absolutely buttery smooth. =P I want a perfect unattended update. NO USE CHANGES NO MANUAL UNINSTALLS NO MANUAL ANYTHING. I want to say "update this crap" with my existing scripts and to walk away. As my CPU is 100% committed right now, this will have to be with the software I have right now. You have 6 months to get Gentoo ready to do this. =| OR RIOT -- Clowns feed off of funny money; Funny money comes from the FED so NO FED -> NO CLOWNS!!! Powers are not rights.
[gentoo-user] conditional sysctl tweaks?
What is the cleanest way to handle the situation when a new sysctl knob is introduced by a kernel release and I want to use it, but I also have older kernels around? I think the error is not fatal so I can simply add it to sysctl.conf, but the message is going to be ugly. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: escape from i3lock
On 2019-07-10 23:46, artur.tamm...@gmail.com wrote: > #!/bin/bash > setxkbmap -option srvrkeys:none > i3lock -c 003355 -n > setxkbmap -option '' Thanks for the idea! It won't work as is for me because I already use some non-default xkb options. But it is closer than anything that has come up yet. I'll get there. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: escape from i3lock
On 2019-07-11 10:43, Adam Carter wrote: > > No, it's my way to run things as root, in general. I distrust su, sudo > > and friends. > > > > su is mature, well understood and the standard way of doing things. If you > had run an extra term in your X session that had been su'd to root, you > wouldn't be exposing a root shell at the console. Perhaps your distrust of > su is making you less secure? You might be thinking in absolutes, eg "su > is insecure" but its better to think along the lines of "is > more or less secure than su?" I have specific reason for the distrust [1]. Your argument regarding _relative_ security is well taken. But I still feel that having the root shell outside of my X session would be more secure, providing I close the switching hole. [1] https://www.openwall.com/lists/owl-users/2004/10/20/6 -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Massive kmail breakage with mariadb-10.4.6
On Wednesday, 10 July 2019 18:40:04 BST Mick wrote: > Normally, I don't think any of the above is required. From what I recall > akonadiserver runs mysql_upgrade each and every time akonadiserver is > launched. However, if akonadi can't run the kdepim mysql following a > database version update, then you'll need to look deeper into it. It turns out to be a bug in mariadb-10.4.6: https://bugs.kde.org/show_bug.cgi?id=409224 and https://bugs.gentoo.org/688746 Meanwhile, thanks to Mick, I've learned a few things about the akonadi database. -- Regards, Peter.
Re: [gentoo-user] Massive kmail breakage with mariadb-10.4.6
On Wednesday, 10 July 2019 18:40:04 BST Mick wrote: > On Wednesday, 10 July 2019 14:31:19 BST Peter Humphrey wrote: > > On Wednesday, 10 July 2019 10:06:01 BST Peter Humphrey wrote: > > > On Wednesday, 10 July 2019 00:06:43 BST Adam Carter wrote: > > > > > I've just tried upgrading mariadb again while watching it, and got > > > > > similar > > > > > results. I did notice that an error notice came up about being > > > > > unable > > > > > to > > > > > store > > > > > a message received via POP3, which is my main incoming source. I > > > > > can't > > > > > quote > > > > > exactly because the notice disappeared too soon. > > > > > > > > > > Back to 10.3.16 for now. > > > > > > > > Just to confirm, when you say upgrade you mean something like; > > > > emerge -u mariadb > > > > systemctl restart mariadb > > > > mysql_upgrade -u root -p > > > > > > Akonadi runs an instance of mariadb for its own use, without reference > > > to > > > what else might be running on the machine. > > > > > > I've never had to run mysql_upgrade before, and I can't find a way to do > > > it > > > manually because of this in .local/share/akonadi/mysql.conf: > > > > > > # Do not listen for TCP/IP connections at all > > > skip_networking > > > > > > Maybe I could comment that out temporarily, but I don't know what else > > > might be affected. Otherwise it looks like creating a new user for > > > myself > > > and importing the message archive. > > > > Well, I tried that but when I started kmail to set it up again, it crashed > > after telling me it had failed to get a lock. On what, it didn't say. > > /usr/bin/akonadi_control launches /usr/bin/akonadiserver, which lunches > /usr/ sbin/mysqld: > > /usr/bin/akonadi_control > > \_ /usr/bin/akonadiserver > > \_/usr/sbin/mysqld > > They're all running as the user who launches kmail, i.e. yourself. Also, > unless you have tweaked access to the database to allow TCP, it will only > use a local Unix socket. Have a look in your /tmp fs for this socket name. > If your kdepim user is logged in as user 'peter', I'm guessing you'll see > something like this, as long as akonadiserver is running: > > /tmp/akonadi-peter.XX/mysql.socket > > You could try running mysql_upgrade on this, but the command will request > access to default mysql database tables and its socket under > /var/run/mysqld/, which I assume you won't be running unnecessarily just > for a Plasma/KDE desktop. Consequently the incantation will fail. > > Instead, you could try running the individual commands mysql_upgrade runs > yourself, only on the akonadi tables. Here's my attempt: > > $ /usr/bin/mysqlcheck -u michael --all-databases --check-upgrade > --auto-repair --socket=/tmp/akonadi-michael.ZtUWTD/mysql.socket > akonadi.collectionattributetable OK > akonadi.collectionmimetyperelation OK > akonadi.collectionpimitemrelation OK > akonadi.collectiontableOK > akonadi.flagtable OK > akonadi.mimetypetable OK > akonadi.parttable OK > akonadi.parttypetable OK > akonadi.pimitemflagrelationOK > akonadi.pimitemtable OK > akonadi.pimitemtagrelation OK > akonadi.relationtable OK > akonadi.relationtypetable OK > akonadi.resourcetable OK > akonadi.schemaversiontable OK > akonadi.tagattributetable OK > akonadi.tagremoteidresourcerelationtable OK > akonadi.tagtable OK > akonadi.tagtypetable OK $ /usr/bin/mysqlcheck -u prh --all-databases --check-upgrade --auto-repair -- socket=/tmp/akonadi-prh.1l0Gu6/mysql.socket akonadi.collectionattributetable OK akonadi.collectionmimetyperelation OK akonadi.collectionpimitemrelation OK akonadi.collectiontableOK akonadi.flagtable OK akonadi.mimetypetable OK akonadi.parttable OK akonadi.parttypetable OK akonadi.pimitemflagrelationOK akonadi.pimitemtable OK akonadi.pimitemtagrelation OK akonadi.relationtable OK akonadi.relationtypetable OK akonadi.resourcetable OK akonadi.schemaversiontable OK akonadi.tagattributetable OK akonadi.tagremoteidresourcerelationtable OK akonadi.tagtable OK akonadi.tagtypetable OK That's on the older
