| psionic | rwp lmao i did it under my 20 years sa career so many times even when doublechecking DD | 00:23 |
|---|---|---|
| psionic | my other worldclass screwups were being logged in on a plethora of servers and rebooting or shutting down the worng server | 00:23 |
| psionic | so I just renamed both halt shutdown poweroff reboot on those | 00:23 |
| psionic | Laughs Out Loud | 00:23 |
| systemdlete | If ssh server is set to "PermitRootLogin prohibit-password" then I try to set up root passwordless login, I can't login to so much as copy local root's public key to the server! | 00:25 |
| systemdlete | Do I need to set it to "yes" temporarily to do this first? | 00:26 |
| systemdlete | (this one has me scratching my head) | 00:26 |
| systemdlete | sorry if this is sysadmin 101 stuff... | 00:27 |
| sadsnork | systemdlete, I believe some people [not me] use ssh-copy-id somehow, but rather than temporarily changing your sshd_config it might be easier to connect once as a user (with a password rather than key) and su to paste in your authorized_keys for root. | 00:33 |
| systemdlete | ssh-copy-id won't work either because it blocks all ssh access | 00:34 |
| systemdlete | and you are right, maybe that is only way to do this | 00:35 |
| ham5urg | Is there a filesystem which preserves a file before it is rw-opened? So a rsync would sync the file in it last closed version. E.g. a user rw-opens many files, alter these and let these stay open over night. In such case, I would like to synchronize the last closed version of any file. | 00:42 |
| sadsnork | Assuming you've done a fresh Devuan install, there is very likely a non-priv user account already that should allow you to quickly push your key to the root account. If you have a fancy SSH client [I like asbru-cm] you might also find that it has a way to script it too. :-) | 00:43 |
| rwp | systemdlete, You have the center of the problem understood. I think the way people use PermitRootLogin without-password is to set up the key in the image ahead of time so it is available at the first boot. | 02:25 |
| systemdlete | I've figured out a means for myself here. Thanks. | 02:25 |
| rwp | Personally I believe in math and use long random generated passwords. Therefore I have no fear about "PermitRootLogin yes". It cannot be guessed. | 02:26 |
| rwp | The default Devuan installation will set up the install user that you create at install time as able to either su or sudo to root. | 02:27 |
| rwp | So... Interactively one can log in as that user, then su or sudo to root, then install the ssh key, and then after doing that manually "PermitRootLogin without-password" works. | 02:27 |
| adhoc | rwp: having strong passwords is great | 02:28 |
| adhoc | rwp: most people don't though | 02:28 |
| adhoc | I don't see the point in sudo | 02:29 |
| adhoc | but it does make some people happy not to have to remember a second password | 02:30 |
| adhoc | and the XKCD joke ... | 02:31 |
| rwp | I use both su and sudo. But right, some people just turn their nose up, screw up their face, stand upside down, and just refuse to think about having TWO passwords, for user and for root. So in that case sudo is good for them. | 02:36 |
| rwp | For passwords if it is something you can remember then it isn't random enough. I use "pwgen -s 16 3" most often to generate 3 random passwords from which I will pick one. | 02:37 |
| Hydragyrum | rwp, passphrases > passwords | 02:55 |
| Hydragyrum | a 16-char random password's got less entropy than a 3-5 word passphrase | 02:55 |
| rwp | Uhm... What? Is that plausible? I would like an independent audit to check our math. :-) | 02:56 |
| rwp | For that though we get offtopic and should escape to #devuan-offtopic | 02:57 |
| fluffywolf | some quick math says there's about a billion times as many 16-char passwords as 5-word passwords. | 02:59 |
| fluffywolf | actually, only 4.6 million. | 03:00 |
| * fluffywolf did less-quick math the second time | 03:00 | |
| fluffywolf | ~$ echo "96^16 / $(wc -l /usr/share/dict/words | cut -d ' ' -f 1) ^ 5" | bc | 03:01 |
| fluffywolf | 4621880 | 03:01 |
| fluffywolf | but, yeah, they're both very very large numbers. | 03:01 |
| rwp | That is not a great dictionary though as people will not be using those as "words" to choose from. | 03:01 |
| rwp | Better to use something like the EFF's curated word list of practical words for a passphrase. https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases | 03:01 |
| fluffywolf | #words^5 is 11259548834977651098112001, which is a big number. | 03:02 |
| fluffywolf | bah. that's just for people who don't want their auto-generated passwords for customers to be "fuck e magnetohydrodynamic bewusstseinslage yiff". :P | 03:05 |
| rwp | The practical EFF list of is 7776 words. 7776^5=28,430,288,029,929,701,376 which is certainly a very big number. 62^16=47,672,401,706,823,533,450,263,330,816 which also being a large number is also an even larger number. | 03:08 |
| rwp | In either case though I think we can all be confident that it would not be possible to brute force through a networked ssh login attempt. | 03:09 |
| fluffywolf | except in the real world, 5% of them are "password"... | 03:09 |
| rwp | It's heat death of the universe in either case. Plus fail2ban (FTW!) will drop repeated failing attempts automatically. Highly recommended. | 03:09 |
| rwp | https://en.wikipedia.org/wiki/List_of_the_most_common_passwords | 03:10 |
| fluffywolf | I get so many failed ssh logins that I finally gave up and changed the port on both my servers. | 03:10 |
| fluffywolf | one of my servers was getting unintentionally DOSed trying to handle all of them. | 03:10 |
| fluffywolf | looks like password being 5% is outdated. now 4% is 123456? :P | 03:11 |
| onefang | Alas fail2ban needs some work, otherwise it fails2ban. | 04:45 |
| fluffywolf | lol | 04:46 |
| Xenguy | "I'm sorry Sir, you're *cough* fails to ban..." | 04:48 |
| hyrcanus | how do i disable gtk's drag and drop for all apps, e.g. in firefox | 05:34 |
| hyrcanus | i want to never see anything drag | 05:34 |
| Xenguy | oh gawd | 05:34 |
| hyrcanus | i need to hilight a url in ddg results | 05:34 |
| hyrcanus | and i cannot because i get a drag event | 05:34 |
| Xenguy | Sounds like a difficult and obscure problem, maybe | 05:35 |
| Xenguy | Is it a #gtk thing? | 05:36 |
| hyrcanus | i'll try gtk-dnd-drag-threshold=2861 in .gtkrc-2.0 | 05:37 |
| hyrcanus | oh maybe it's gtk_drag_check_threshold | 05:38 |
| golinux | Mouse problem? | 05:38 |
| hyrcanus | no, try to hilight a youtube url in ddg results | 05:38 |
| golinux | Mine is currently acting up with right click options | 05:38 |
| golinux | I do that all the time | 05:39 |
| golinux | afk | 05:39 |
| hyrcanus | increasing drag threshold worked. i can hilight ddg results again | 05:42 |
| Xenguy | There's hope, after all | 05:43 |
| hyrcanus | course ddg corrupts the copied text with their javascript | 05:43 |
| hyrcanus | i told them don't allow code in browsers | 05:43 |
| Xenguy | But they wouldn't listen | 05:43 |
| hyrcanus | the spirit of satan lives in their hearts | 05:44 |
| Xenguy | And there you have it | 05:44 |
| hyrcanus | yup disabling script gets me an uncorrupted text | 05:45 |
| Xenguy | Well all hail freedom then | 05:46 |
| hyrcanus | high drag threshold fixes gimp too | 05:47 |
| Xenguy | You got it made in the shade | 05:48 |
| hyrcanus | a good start for /etc/hosts http://0x0.st/-g5P.txt | 09:30 |
| UsL | I hate paste sites that blocks Tor.. | 09:31 |
| UsL | and silently like 0x0.st does as well.. No 403 or anything. Just empty screen. | 09:32 |
| hyrcanus | https://gist.github.com/djaiss/85a0ada83e6bca68e41e has some of them | 09:34 |
| hyrcanus | i find i have to chattr +i /etc/hosts | 09:38 |
| hyrcanus | what is removing it? | 09:38 |
| hyrcanus | should firewall it as well ofc | 09:39 |
| UsL | don't know. Firewall your hosts file? How do you mean? | 09:44 |
| hyrcanus | egress; run through the list, get ip addresses, add to blocklist in iptables | 09:47 |
| hyrcanus | for those things that bypass host dns | 09:47 |
| UsL | ah, I see. | 09:47 |
| hyrcanus | might do better with a whitelist actually | 09:48 |
| UsL | I have yet to encounter such a thing. Only thing that bypass hosts here is the local http proxy which is chained to Tor. | 09:51 |
| UsL | err, I totally switched dns and hosts right now. I need sleep. Gnight. | 09:55 |
| hyrcanus | ttyl | 09:55 |
| DPA | I just upgraded to chimaera. I still have a small problem though. It replaced wicd with NetworkManager. Now I can't connect to WLAN, it says I'm unauthorized. It seams there is no polcit agent running. How can I fix this? | 14:59 |
| DPA | *polkit agent | 14:59 |
| DPA | I can't start one either. There seams to be something wrong with the XDG_RUNTIME_DIR... | 15:02 |
| DPA | And the path in the DBUS_SESSION_BUS_ADDRESS doesn't exist. That seams familiar. | 15:03 |
| gnarface | polkit agent maybe just missing? it would be in another package | 15:05 |
| gnarface | apt-cache search ^libpolkit-agent | 15:06 |
| gnarface | dpkg -l |grep 'polkit.agent' | 15:06 |
| DPA | I have a few installed. I remember I did something in the lightdm config once which probably got overwritten in the update, I'll have to check what that was. | 15:07 |
| gnarface | DPA: if you changed graphical logins, it might have also changed which permissions backend library you need to use | 15:16 |
| gnarface | in ascii and beowulf it wasn't smart enough to pick the right one, it would just install both and they would choke each other | 15:16 |
| gnarface | i assume that problem has still persisted into chimera if you're having trouble with it | 15:16 |
| gnarface | in theory installing the right one and/or removing the others should fix it | 15:17 |
| gnarface | at least if it's the same problem as before | 15:17 |
| DPA | No, that's fine here. | 15:17 |
| DPA | See, the permission backend stuff is all elogind: https://pastebin.com/0KtEAis7 | 15:20 |
| systemdlete | My logwatch report tells me that ssh changed a users password -- I did not change ANY passwords anywhere yesterday. So what does this really mean? (I am assuming that the wording is misleading) | 17:23 |
| GyrosGeier | single-user box? | 17:23 |
| systemdlete | yes | 17:23 |
| GyrosGeier | because passwords can be changed during login if they are expired, but the user notices that generally | 17:24 |
| systemdlete | I'm not following, sorry. | 17:24 |
| GyrosGeier | the other thing that may have happened would be a hash change | 17:24 |
| systemdlete | The only way I know of to change passwords on *nix is to go to the command line (once logged in that is) and run "passwd" | 17:25 |
| GyrosGeier | e.g. if that is the first login after an upgrade, then it can replace the encrypted hash of the password with a new one | 17:25 |
| systemdlete | what do you mean by "after an upgrade" -- upgrade of what exactly? | 17:26 |
| GyrosGeier | whole system | 17:26 |
| systemdlete | no, nothing like that here | 17:26 |
| GyrosGeier | more specifically, the "shadow" package | 17:26 |
| GyrosGeier | there is a system-wide default for what hashing algorithm should be used for passwords, and the algo that was actually used is also encoded in the password field | 17:26 |
| onefang | What was the actual log text? | 17:27 |
| GyrosGeier | so when the default changes, old passwords are checked against the hash with the old method, and then the hash is rewritten with the new algo | 17:27 |
| systemdlete | Changed users password: | 17:27 |
| systemdlete | sshd changed password: 1 Time(s) | 17:27 |
| systemdlete | (from the logwatch report) | 17:27 |
| GyrosGeier | systemdlete, the actual log line would be interesting, not just the summary | 17:28 |
| systemdlete | Let me be absolutely clear: I did not run "passwd" anwhere at anytime for any login anywhere yesterday | 17:29 |
| onefang | Might be the "sshd" user had their password changed. Logwatch can be a little ambiguous sometimes. | 17:29 |
| hyrcanus | from /var/log/auth.log.* | 17:29 |
| systemdlete | Oct 6 23:36:19 mysys usermod[6731]: change user 'sshd' password | 17:30 |
| systemdlete | Oct 6 23:36:20 mysys chage[6736]: changed password expiry for sshd | 17:30 |
| systemdlete | (hostname obfuscated) | 17:30 |
| systemdlete | I DID install openssh-server around that time | 17:31 |
| onefang | That looks like what I said then. | 17:31 |
| gnarface | systemdlete: it's saying usermod changed sshd's password | 17:32 |
| systemdlete | ok, but I did not run usermod. Something else did, like apt maybe? | 17:32 |
| gnarface | never noticed this before but i would also assume it coincides with the post-installation setup of openss-server | 17:32 |
| gnarface | openssh-server | 17:32 |
| gnarface | i mean | 17:33 |
| onefang | So you install opennsh-server, IT creates the sshd user, and sets their password. | 17:33 |
| systemdlete | yeah, I figured this out now, thanks. That has got to be the most misleading advertisement I've ever seen. I actually thought it was telling me that someone had managed to login into my system to hijack it. | 17:34 |
| gnarface | i'm honestly not sure sshd is supposed to have a password but maybe it says that even if it's setting it to "no password" | 17:34 |
| gnarface | i would double-check the groups, passwd and shadow files to make sure nothing looks insane | 17:34 |
| onefang | Like I said, logwatch can be ambiguous. For along time I was wondering what sort of error a "Level error" was. lol | 17:35 |
| systemdlete | No, this makes sense to me now. | 17:35 |
| gnarface | there should also be an apt log you can use to verify that the installation time of openssh-server coincides | 17:35 |
| onefang | When I eventually saw "Level critical" as well the shoe dropped. | 17:36 |
| systemdlete | I'm no longer concerned. I wish apt and its friends would be a little bit clearer in its terminology and organization. But given that is a debian thing, I suppose that | 17:36 |
| systemdlete | will not ever get fixed. | 17:36 |
| gnarface | i have hope for the future but we'll have to fix the public school system first | 17:37 |
| hyrcanus | by ending it | 17:37 |
| systemdlete | gnarface: +1 | 17:38 |
| systemdlete | not sure "ending it" will improve matters | 17:38 |
| systemdlete | but this is getting OT | 17:39 |
| systemdlete | thanks for confirming my suspicions and addressing my concerns, everyone. I feel relieved. | 17:39 |
| hyrcanus | why do you think people who can afford to, send their kids to private schools | 17:43 |
| hyrcanus | give the people back their school tax money and let them choose which school to send their child to | 17:43 |
| onefang | Take that to #devuan-offtopic. | 17:44 |
| hyrcanus | you wouldn't want the government choosing your OS for you | 17:44 |
| hyrcanus | i'm sorry, joerg decided he didn't want me talking in -offtopic | 17:46 |
| hyrcanus | however i've corrected gnarface's error and am done with that subject | 17:46 |
| gnarface | oh, now i know why they silenced you in -offtopic | 17:47 |
| gnarface | that was unacceptably hostile and wrong-minded | 17:47 |
| hyrcanus | that's a syntax error | 18:11 |
| joerg | triggers (incomplete list): *) start a conversation thread with an obviously false and conflict triggering statement that makes all trolling-sensors yell *) repeatedly use expletive attacks and ad-hominem, as well as NSFW dusgusting speech *) threaten people *) spread potentially hazardous life-threatening advise or fake news *) threaten chanop to extort them a certain measure zaken or not taken *) cause other users to ask chanops to take action to sort the | 18:30 |
| joerg | situation | 18:30 |
| buZz | lol | 18:32 |
| buZz | joerg: I'LL JUMBLE THE LETTERS IN YOUR NAME IF YOU KEEP THIS UP | 18:32 |
| buZz | JEORG! | 18:32 |
| buZz | :D | 18:32 |
| buZz | lolol | 18:32 |
| joerg | not related to "speaking in $cahnnel" - those triggers apply universally | 18:32 |
| * joerg pricks buzz' back with a long thin stick | 18:37 | |
| buZz | <3 | 18:37 |
| * buZz hugs joerg | 18:37 | |
| hyrcanus | you should stop lying, joerg | 18:40 |
| joerg | you should wake up from that nightmare you're in | 18:42 |
| joerg | see, I don't even intend to make the horror worse for you by calling for a citation showing a lie of me which you can't provide without exposing your own misconceptions and weird intentions | 18:47 |
| joerg | and I call for staying on-topic in this channel now. If you want to continue this you're welcome to PM me (well... :-x) | 18:48 |
| hyrcanus | ontopic, what kid introduced tmpfs | 19:04 |
| hyrcanus | ah it's just being used by the python idiots for things it shouldn't | 19:05 |
| hyrcanus | "i don't want to keep these gigabytes of downloads, so I'll use tmpfs" | 19:06 |
| hyrcanus | /dropkick | 19:06 |
| hyrcanus | they should have kept the name shmfs | 19:17 |
| hyrcanus | https://rwmj.wordpress.com/2012/09/12/tmpfs-considered-harmful/ | 19:25 |
| hyrcanus | so lets fix devuan guys | 19:26 |
| hyrcanus | and restore a sane /tmp | 19:26 |
| hyrcanus | that means not allowing lunatics to lead you | 19:27 |
| fluffywolf | is there something wrong with /tmp? | 19:27 |
| hyrcanus | so who in debian or devuan decided to put /tmp in ram | 19:53 |
| hyrcanus | and shouted down all the sane opposition | 19:53 |
| gnarface | is this in chimaera? | 19:54 |
| gnarface | or is this with the live image? | 19:55 |
| gnarface | or auto-partitioning or something? | 19:55 |
| gnarface | where exactly are you alleging the default changed? | 19:56 |
| hyrcanus | this was a long time ago gnarface | 19:57 |
| hyrcanus | we really should figure out who was for it | 19:57 |
| gnarface | i never use the auto-partitioner so it isn't something i've seen | 19:57 |
| hyrcanus | /tmp is supposed to be a partition on a hard drive, not ram | 19:57 |
| fluffywolf | /tmp in ram sounds fine to me. it's been like that for a very long time. | 19:58 |
| gnarface | i sometimes put it in ram for certain hardware (raspberry pi with only flash storage for example) | 19:58 |
| hyrcanus | maybe it's a remnant from the ubuntu i converted from. anyway yeah | 19:58 |
| fluffywolf | debian always wiped the partition on boot back when it was a partition | 19:58 |
| gnarface | not always, they started doing it in like sarge or etcher i think | 19:59 |
| gnarface | but i think it's supposed to be wiped | 19:59 |
| gnarface | bsd always wiped it | 19:59 |
| fluffywolf | it's been long enough that I don't remember when it changed. :) | 19:59 |
| fluffywolf | having it in ram seems like a perfectly good default. | 19:59 |
| hyrcanus | now i remember when they started pushing this | 19:59 |
| fluffywolf | what advantage to having it on disk is so important to you? | 20:00 |
| gnarface | you're supposed to use /var/tmp if you want it to persist, though i think for some reason i remember hearing they started flushing that one too anyway now or symlinked them together or some shit | 20:00 |
| fluffywolf | if you were counting on it persisting across reboots, that is very, very much not what /tmp is or has ever been for. | 20:01 |
| hyrcanus | this is a fine example of how corrupting the word / label of a thing can lead to lots of confusion and harm down the road | 20:01 |
| fluffywolf | what confusion or harm has occured? | 20:02 |
| hyrcanus | ramfs, shmfs were sensible, emphasizing the qualitative difference in the nature of it | 20:02 |
| hyrcanus | 'tmpfs' obscures the important distinction, confuses people, makes them think it's "for temporary files" | 20:02 |
| fluffywolf | again, what confusion or harm has occured? a real example of a non-idiotic situation where this is a problem. | 20:03 |
| gnarface | eh, i don't disagree but i don't see that it's a big deal either | 20:03 |
| fluffywolf | of course it makes them think it's for temporary files. that's because it's for temporary files. this is the opposite of confusing? | 20:03 |
| gnarface | i remember being briefly confused about it but not past when someone explained to me how it works; after that the name didn't really matter to me | 20:04 |
| fluffywolf | let me guess, you came up with some broken use case where you expected /tmp to persist over a reboot, and it didn't work, and now it's the entire rest of the world's problem? | 20:04 |
| gnarface | hehe /usr/local/var/tmp | 20:05 |
| fluffywolf | it's been tempfs since kernel 2.4 apparently. you'd think if it were some major problem, someone would have noticed by now. | 20:05 |
| fluffywolf | tmpfs | 20:05 |
| fluffywolf | it's been literally more than 20 years. | 20:07 |
| fluffywolf | bbl, time for work | 20:07 |
| rwp | I use /tmp tmpfs but there are situations where it is problematic due to the way /tmp might be used. | 20:08 |
| rwp | Engineering applications sometimes write HUGE files into /tmp that exceed all working space. Couple that with Linux memory overcommit and the OOM Killer and that is a problem. | 20:09 |
| rwp | But technical users like that are free to make sweeping customizations as needed to support their workflow. I always disable Linux memory overcommit for example. | 20:10 |
| fluffywolf | tmpfs won't use more than half of ram and will swap if needed, I believe. but, for odd use cases, it's trivial to make it a directory or partition. | 20:10 |
| fluffywolf | bbl | 20:10 |
| rwp | Later! :-) | 20:10 |
| rwp | Also the Linux distribution default has been to purge /tmp on boot for literally decades. Some people disable it. But purging avoids some class of problems since /tmp is used for system stuff that becomes stale on a reboot. | 20:12 |
| rwp | Therefore /var/tmp has become the Linux system location for persistent storage. Meaning in mutt I set tmpdir="/var/tmp" to avoid losing my compose mail if the system crashes. | 20:13 |
| rwp | This is all outside of whether /tmp is a tmpfs or not. But given a purge of /tmp on boot then making it a tmpfs isn't awful. | 20:13 |
| DPA | I have PCs where I mount tmp, and I have some where I forgot. In most cases, it doesn't matter. On my linux phone, I make it a tmpfs, because I want to prolong the lifetime of the internal non-replacable emmc. And in my PXE environment, I use a readonly NFS as root, so I need tmpfs there too. | 20:14 |
| hyrcanus | do you also disable the OOM killer in sysctl.conf rwp? | 20:14 |
| hyrcanus | when you disable overcommit | 20:15 |
| rwp | Right DPA. It's one of those complex problems that needs good understanding of the ram versus disk versus updated flush tradeoffs. | 20:15 |
| rwp | Yes hyrcanus I disable overcommit in /etc/sysctl.d/vm.conf with "vm.overcommit_memory = 2" there. | 20:16 |
| hyrcanus | do you also set vm.oom-kill = 0 rwp? | 20:16 |
| rwp | And then programs get failures from fork() and malloc() which they can handle, rather than having the kernel OOM Killer try to guess what to do. | 20:17 |
| rwp | hyrcanus, I do not set vm.oom-kill = 0 since I don't think vm.oom-kill is a valid setting on any kernel I use. Did you make a typo there? | 20:23 |
| zeron | Hey guys! I'd like to report something that MIGHT be a bug: installing a barebones system from Chimaera netinstall.iso sith expert install creates an incomplete sources.list file -- it does not include the main repo `deb http://deb.devuan.org/merged chimaera` -- it's just isn't there. All the others are present -- chimaera-updates, chimaera-security and even chimaera-backports, but not the main one. | 20:25 |
| zeron | Without this repo nothing can be installed -- tasksel isn't working, DE uninstallable, even aptitude could not be installed. I had to manually add `deb http://deb.devuan.org/merged chimaera main` to the sources in order for it to work. Now I can install stuff. | 20:27 |
| hyrcanus | thanks rwp. i didn't make a typo. | 20:28 |
| rwp | zeron, That does sound frightening! During the installation there is a dialog that asks about setting up sources.list, which then stores the answer as a debconf thing. Let me look that up... | 20:28 |
| rwp | zeron, Which installer image did you use? (There are several possible.) | 20:30 |
| zeron | I was using devuan_chimaera_4.0.beta-20210927_amd64_netinstall.iso | 20:32 |
| rwp | zeron, Thanks! I am going to try it now and see if I can reproduce it. | 20:34 |
| rwp | Unfortunately the folks who I think really need to look are not in the channel at the moment. | 20:34 |
| zeron | During the installation there was a question of whther to use deb.devuan.org or pkgmaster.-something... But no other question relating to sources. | 20:34 |
| rwp | Just as background there pkgmaster is the master so please avoid hits there if possible (I don't know why they even offer it as a choice) and deb.devuan.org is the mirror network. | 20:35 |
| zeron | @rwp, but you can pass this information on to those who need to know it? I have to go offline. | 20:36 |
| rwp | Thanks for the report zeron! I'll try to reproduce it and pass it along later when the-ones-who-know come online. | 20:36 |
| zeron | When I opened sources.list it was the pkgmaster that was listed. I changed it to deb.devuan.org. | 20:36 |
| zeron | Thanks! | 20:37 |
| golinux | Posting a note about the repos now. | 20:51 |
| rwp | golinux, I note that devuan_chimaera_4.0.beta-20210927_amd64_netinstall.iso has been superseded by devuan_chimaera_4.0.beta-20211004_amd64_netinstall.iso already. | 20:58 |
| golinux | rwp . . . I just put a note for rrq to check the issues mentioned above. IIUC new isos are generated every Monday. | 21:05 |
| rwp | golinux, I just ran through a basic install using devuan_chimaera_4.0.beta-20211004_i386_netinstall.iso and resulted in this https://paste.debian.net/plain/1214655 sources.list file. | 21:19 |
| rwp | At the sources dialog I selected deb.devuan.org not pkgmaster but pkgmaster still appeared for the security lines. | 21:20 |
| rwp | I am imagining that someone saw "security" upgrades and thought _avoid all mirrors_. But is that a good or bad thing here? | 21:22 |
| golinux | I have posted these notes for rrq | 21:26 |
| rwp | Anyway... As such I am unable to reproduce the issue reported by zeron. I did have sources.list entries with the main repo and specifically tried tasksel since that was mentioned and it worked. | 21:26 |
| golinux | Really appreciate your testing. That was above and beyond! | 21:26 |
| rwp | I have been meaning to spend more time on chimaera installation. I have a couple of upgraded systems. But haven't been working through the installer for it. | 21:27 |
| rwp | Interesting that while at tasksel I unselected all to install only the basics (to speed things along) no desktop and I do not have either wicd or network-manager installed. | 21:28 |
| rwp | It's installed ifupdown and that has DHCP'd okay no problem. But from the reports I had expected NM to have been installed. | 21:28 |
| rwp | I guess that is only pulled in if a DE is selected for installation. | 21:29 |
| rwp | https://paste.debian.net/plain/1214656 shows that if I install the default DE then network-manager is pulled in. | 21:30 |
| rwp | So far everything looks to be all correct, other than using pkgmaster for security which is debatable good or bad. | 21:31 |
| rwp | I'll note that I did the install in a VM and that was why I selected the 386 iso as the result is smaller RAM footprint than the amd64 image. | 21:32 |
| rwp | I usually install small VMs as 386 and install bare metal as amd64. | 21:32 |
| rwp | As an experiment I logged into this new pristine chimaera VM using ssh. Then did "apt-get install connman" which I considered a dangerous action over ssh. | 22:47 |
| rwp | Everything installed okay up until "Starting Connection Manager:" appeared. At that point it re-DHCP'd a new address. Which of course hung the ssh connection. | 22:48 |
| rwp | I was able to then ssh back in using the new IP address. Everything seemed okay at that point and connmand and dhclient is running. | 22:48 |
| rwp | Along with wpa_supplicant too. Which is odd as there is no WiFi devices on this system. So I wonder what wpa_supplicant would do in that case. | 22:49 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!