| 2023-05-07 00:24:02 +0200 | albatross | (~albatross@130.44.143.160) |
| 2023-05-07 00:27:54 +0200 | <albatross> | I'm not sure if this is an xmonad problem, but I managed to lock myself out of X and don't know how to get back into it. I can still access virtual consoles 2 through 6 |
| 2023-05-07 00:28:06 +0200 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) |
| 2023-05-07 00:28:20 +0200 | unclechu | (~unclechu@2001:470:69fc:105::354) |
| 2023-05-07 00:30:32 +0200 | <albatross> | X is still running, I just don't know how to get to it |
| 2023-05-07 00:45:24 +0200 | <geekosaur> | if alt-f7 doesn't work then it's an X server problem |
| 2023-05-07 01:01:02 +0200 | <albatross> | Well, I tried restarting xmonad and somehow X closed, unfortunately |
| 2023-05-07 01:02:03 +0200 | <albatross> | So the immediate problem is solved by startx. But I'm not sure what happened and can't seem to duplicate how I got here sooo oh well |
| 2023-05-07 01:03:28 +0200 | <albatross> | I thought it would be possible to restart xmonad without closing X? When I tried "xmonad --restart" it didn't work, and when I killed xmonad X died too |
| 2023-05-07 01:07:07 +0200 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) (*.net *.split) |
| 2023-05-07 01:07:07 +0200 | yosafbridge | (~yosafbrid@static.38.6.217.95.clients.your-server.de) (*.net *.split) |
| 2023-05-07 01:07:07 +0200 | vanvik | (~vanvik@185.201.120.72) (*.net *.split) |
| 2023-05-07 01:07:07 +0200 | piele | (~piele@tbonesteak.creativeserver.net) (*.net *.split) |
| 2023-05-07 01:07:07 +0200 | laman2 | (~laman@rego.ai) (*.net *.split) |
| 2023-05-07 01:07:07 +0200 | joshproehl | (~quassel@user/joshproehl) (*.net *.split) |
| 2023-05-07 01:07:07 +0200 | justache | (~justache@user/justache) (*.net *.split) |
| 2023-05-07 01:07:07 +0200 | dminuoso | (~dminuoso@user/dminuoso) (*.net *.split) |
| 2023-05-07 01:07:19 +0200 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) |
| 2023-05-07 01:07:19 +0200 | piele | (~piele@tbonesteak.creativeserver.net) |
| 2023-05-07 01:07:49 +0200 | laman2 | (~laman@rego.ai) |
| 2023-05-07 01:07:55 +0200 | joshproehl | (~quassel@user/joshproehl) |
| 2023-05-07 01:09:03 +0200 | justache | (~justache@user/justache) |
| 2023-05-07 01:09:03 +0200 | justache | (~justache@user/justache) (Max SendQ exceeded) |
| 2023-05-07 01:09:04 +0200 | dminuoso | (~dminuoso@user/dminuoso) |
| 2023-05-07 01:11:19 +0200 | yosafbridge | (~yosafbrid@static.38.6.217.95.clients.your-server.de) |
| 2023-05-07 01:13:28 +0200 | justache | (~justache@user/justache) |
| 2023-05-07 02:23:07 +0200 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2023-05-07 02:30:14 +0200 | <geekosaur> | albatross, why were you trying to restart it? |
| 2023-05-07 02:30:44 +0200 | <geekosaur> | if you make chyanges to your config and you want them to take effect, you press (by default) mod-q. |
| 2023-05-07 02:31:10 +0200 | <albatross> | I wasn't in X to do that |
| 2023-05-07 02:31:33 +0200 | <geekosaur> | `xmonad --restart` is only half of that, and it restarts the existing configuration without rebuilding it. you need `xmonad --recompile` to do that part |
| 2023-05-07 02:32:07 +0200 | <albatross> | neither command worked, gave an error message like "user error (openDisplay)" |
| 2023-05-07 02:32:18 +0200 | <geekosaur> | also `xmonad --recompile` and `xmonad --restart` need to be run within X because thjey send X messages |
| 2023-05-07 02:32:40 +0200 | <albatross> | X was still running, I just wasn't in X |
| 2023-05-07 02:32:41 +0200 | <geekosaur> | well, recompile should work but restart won't be able to connect to the X server |
| 2023-05-07 02:33:01 +0200 | <albatross> | like I could use vtty |
| 2023-05-07 02:33:07 +0200 | <geekosaur> | but because you weren't in X, restart couldn't connect to it |
| 2023-05-07 02:35:17 +0200 | <albatross> | surely those commands have no one to distinguish being run from a vtty or an xterminal? so long as there is an x server running they would work, I would think |
| 2023-05-07 02:35:29 +0200 | <geekosaur> | and even if it somehow managed to authorize with the X server from outside, it still wouldn't have done anything noticeable unless you had changed your config and rebuilt it with `xmonad --recompile` |
| 2023-05-07 02:36:40 +0200 | <geekosaur> | X used to work that way. it meant anyone who could get into your syste,m from a network connection could do things like sniff passwords. X is insecure enough as it is |
| 2023-05-07 02:36:42 +0200 | <albatross> | or does xterm set up some env variables with information about the x server that is missing from a virtual console |
| 2023-05-07 02:37:22 +0200 | <albatross> | hmmm so is there some way for me to cleanly restart xmonad from command line then? |
| 2023-05-07 02:37:33 +0200 | <albatross> | if I'm stuck in a virtual console |
| 2023-05-07 02:38:25 +0200 | <albatross> | or somehow get back to X. It is academic at this point anyhow |
| 2023-05-07 02:39:27 +0200 | <geekosaur> | you need to find out where the Xauth tickets are stored and point to them with the XAUTHORITY environment variable. sometimes it's stored in ~/.Xauthority and things will work fairly easily, but sometimes they're hidden away by the display manager |
| 2023-05-07 02:40:12 +0200 | <albatross> | I see. That doesn't sound any more secure haha. Good to know for next time I guess... |
| 2023-05-07 02:40:55 +0200 | <geekosaur> | the default isn't, but display managers as I said can hide them away better |
| 2023-05-07 02:41:11 +0200 | <geekosaur> | I'm not sure why more of them don't |
| 2023-05-07 02:41:52 +0200 | <geekosaur> | it was a much simpler world in 1986 when this stuff was designed |
| 2023-05-07 02:42:16 +0200 | <albatross> | I feel like if someone other than me can log in to my system I have bigger issues, really. |
| 2023-05-07 02:42:56 +0200 | <geekosaur> | you mostly do, yes. but this doesn't require full log in to exploit, sadly |
| 2023-05-07 02:43:55 +0200 | <albatross> | ok well I won't pretend to understand the majesties of X internals haha |
| 2023-05-07 02:44:41 +0200 | <immibis> | albatross: is the $DISPLAY environment variable set? |
| 2023-05-07 02:44:53 +0200 | <immibis> | on most/all distributions, just set: export DISPLAY=:0 |
| 2023-05-07 02:45:05 +0200 | <immibis> | and then your X-related commands know which X server to connect to |
| 2023-05-07 02:45:16 +0200 | <albatross> | I can't go back in time to check but I'll keep that in mind for future |
| 2023-05-07 02:45:23 +0200 | <immibis> | that's for your typical case. on weird or multi-user systems it might not be :0 |
| 2023-05-07 02:45:54 +0200 | <immibis> | xauth is usually stored in a place that's accessible to any process in your user account, so it's not an issue, but there is also a way to transfer it to other user accounts if you need that |
| 2023-05-07 02:46:16 +0200 | <immibis> | but DISPLAY is (more-or-less) specific to the terminal |
| 2023-05-07 02:59:40 +0200 | <geekosaur> | it does go a little beyond that; AIUI Fedora uses cgroups to limit access to the session |
| 2023-05-07 03:00:06 +0200 | <geekosaur> | (Debian/Ubuntu/Mint use an older version of cgroups and systemd isn't configured to make use of it anyway) |
| 2023-05-07 03:00:41 +0200 | <geekosaur> | liskin knows more about this, I believe he's got his system set up to use systemd for session control |
| 2023-05-07 04:24:08 +0200 | td_ | (~td@i5387090E.versanet.de) (Ping timeout: 240 seconds) |
| 2023-05-07 04:26:07 +0200 | td_ | (~td@i53870927.versanet.de) |
| 2023-05-07 05:17:34 +0200 | rekahsoft | (~rekahsoft@bras-base-orllon1122w-grc-04-174-88-193-177.dsl.bell.ca) |
| 2023-05-07 05:54:21 +0200 | rekahsoft | (~rekahsoft@bras-base-orllon1122w-grc-04-174-88-193-177.dsl.bell.ca) (Ping timeout: 256 seconds) |
| 2023-05-07 07:25:08 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2023-05-07 07:25:23 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-05-07 08:19:25 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2023-05-07 08:21:31 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-05-07 08:35:54 +0200 | thyriaen | (~thyriaen@91.197.68.193) |
| 2023-05-07 09:19:29 +0200 | thyriaen | (~thyriaen@91.197.68.193) (Ping timeout: 256 seconds) |
| 2023-05-07 09:34:21 +0200 | chomwitt | (~chomwitt@2a02:587:7a1f:b500:1ac0:4dff:fedb:a3f1) |
| 2023-05-07 10:04:18 +0200 | th3m45t3rm1nd | (~th3m45t3r@2401:4900:4048:9364:ac35:cb57:fe94:51d0) |
| 2023-05-07 10:18:28 +0200 | thyriaen | (~thyriaen@91.197.68.193) |
| 2023-05-07 10:25:42 +0200 | thunderrd | (~thunderrd@183.182.115.197) (Remote host closed the connection) |
| 2023-05-07 11:00:11 +0200 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) (Quit: You have been kicked for being idle) |
| 2023-05-07 11:00:11 +0200 | unclechu | (~unclechu@2001:470:69fc:105::354) (Quit: You have been kicked for being idle) |
| 2023-05-07 11:29:57 +0200 | th3m45t3rm1nd | (~th3m45t3r@2401:4900:4048:9364:ac35:cb57:fe94:51d0) (Quit: Client closed) |
| 2023-05-07 13:01:31 +0200 | <liskin> | Debian definitely uses cgroupsv2 these days |
| 2023-05-07 13:01:39 +0200 | <liskin> | And so does its systemd build |
| 2023-05-07 13:01:43 +0200 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) |
| 2023-05-07 13:01:57 +0200 | unclechu | (~unclechu@2001:470:69fc:105::354) |
| 2023-05-07 13:37:52 +0200 | th3m45t3rm1nd | (~th3m45t3r@2401:4900:4048:9364:ac35:cb57:fe94:51d0) |
| 2023-05-07 14:25:07 +0200 | th3m45t3rm1nd | (~th3m45t3r@2401:4900:4048:9364:ac35:cb57:fe94:51d0) (Quit: Client closed) |
| 2023-05-07 14:51:59 +0200 | chomwitt | (~chomwitt@2a02:587:7a1f:b500:1ac0:4dff:fedb:a3f1) (Remote host closed the connection) |
| 2023-05-07 16:54:56 +0200 | tremon | (~tremon@83.80.159.219) |
| 2023-05-07 18:00:07 +0200 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) (Quit: You have been kicked for being idle) |
| 2023-05-07 18:00:07 +0200 | unclechu | (~unclechu@2001:470:69fc:105::354) (Quit: You have been kicked for being idle) |
| 2023-05-07 19:00:36 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-05-07 19:10:23 +0200 | werneta_ | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-05-07 19:14:56 +0200 | tremon | (~tremon@83.80.159.219) (*.net *.split) |
| 2023-05-07 19:14:56 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (*.net *.split) |
| 2023-05-07 19:23:30 +0200 | tremon | (~tremon@83.80.159.219) |
| 2023-05-07 20:19:00 +0200 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) |
| 2023-05-07 20:39:11 +0200 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Read error: Connection reset by peer) |
| 2023-05-07 20:43:08 +0200 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) |
| 2023-05-07 22:14:38 +0200 | thyriaen | (~thyriaen@91.197.68.193) (Quit: Leaving) |
| 2023-05-07 23:39:13 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |