| AlexLikeRock | hi, good morning | 15:22 |
|---|---|---|
| ibanja | I have a private repository that I use for my own personal scripts. My source file is: deb [signed-by=/usr/share/keyrings/my-private-repo.gpg.key] http://repo.myserver.com/debian/ all main | 17:22 |
| ibanja | But I keep getting the error: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4A361055A7690CF6 | 17:23 |
| AlexLikeRock | hi | 17:23 |
| ibanja | the key file is in the correct location. | 17:23 |
| AlexLikeRock | i hace a solution | 17:23 |
| AlexLikeRock | Hold on ... | 17:23 |
| ibanja | ok... thanks | 17:23 |
| AlexLikeRock | 2 options to TRUST | 17:25 |
| AlexLikeRock | 1).- add " [trusted=yes] " to sources.list | 17:25 |
| ibanja | ok... trying that. | 17:26 |
| AlexLikeRock | from : deb http://deb.devuan.org/merged chimaera main non-free-firmware non-free contrib | 17:26 |
| AlexLikeRock | to: | 17:26 |
| AlexLikeRock | deb [trusted=yes] http://deb.devuan.org/merged chimaera main non-free-firmware non-free contrib | 17:26 |
| AlexLikeRock | 2).- add " [allow-insecure=yes] "to surces.list | 17:27 |
| AlexLikeRock | from : deb http://deb.devuan.org/merged chimaera main non-free-firmware non-free contrib | 17:27 |
| AlexLikeRock | to: | 17:27 |
| AlexLikeRock | deb [allow-insecure=yes] http://deb.devuan.org/merged chimaera main non-free-firmware non-free contrib | 17:27 |
| AlexLikeRock | thank you | 17:28 |
| ibanja | I'm still getting the error. | 17:29 |
| AlexLikeRock | dont forget | 17:29 |
| AlexLikeRock | apt update | 17:29 |
| AlexLikeRock | every time you edit the sources.list | 17:30 |
| ibanja | after running apt update: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4A361055A7690CF6 | 17:30 |
| AlexLikeRock | at this web page , you will found more option : https://askubuntu.com/questions/732985/force-update-from-unsigned-repository | 17:31 |
| AlexLikeRock | i think ; apt-get update --allow-unauthenticated | 17:31 |
| AlexLikeRock | its you case | 17:32 |
| ibanja | ok.. checking that page | 17:32 |
| ibanja | Nothing seems to work. This is weird. I might walk away for awhile. | 17:38 |
| AlexLikeRock | -.- | 17:38 |
| AlexLikeRock | rwp gnarface , any idea ? | 17:39 |
| systemdlete | does devuan's cron support extensions like "@reboot"? It doesn't seem to be documented, so I am not sure. | 17:40 |
| AlexLikeRock | systemdlete, do you try with "-f" ? | 17:42 |
| AlexLikeRock | reboot -f | 17:42 |
| ibanja | AlexLikeRock: thanks for the help. I will re-look at it after lunch with fresh eyes. | 17:42 |
| systemdlete | I could always write a custom init script for this, but if it is already supported in cron, I'd just as well use its own facilities. | 17:42 |
| systemdlete | AlexLikeRock, I am talking about crontab, not a cmd line tool | 17:43 |
| AlexLikeRock | good lunk , ibanja , i hope , this web page, help to new ideas | 17:43 |
| systemdlete | I could always try and see if it works, but sometimes unsupported features get skipped in certain programs (I've seen this in some programs) and rebooting to test this might be wearisome. | 17:45 |
| AlexLikeRock | yes | 17:48 |
| * systemdlete notices boot.d -- hmmmm, might be just the thing... | 17:58 | |
| systemdlete | I've looked for doc on boot.d but there just doesn't seem to be any. However, I asked Uncle Duck and somehow they were able to tell me (via their AI tool). It looks like this is a somewhat standard part of linux, but I wonder if it will be supported going forward. | 18:10 |
| ibanja | AlexLikeRock: fixed with the following command: | 18:11 |
| ibanja | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/my-private-repo.gpg.key /usr/share/keyrings/my-private-repo.gpg.key | 18:11 |
| systemdlete | DDG's AI response indicates that this would work for me, but if it will be dropped in the future, I'll be back here hunting for a solution again. And I hate doing that. | 18:11 |
| freem | <ibanja> Nothing seems to work. This is weird. I might walk away for awhile. | 18:11 |
| freem | Just checking, but does `dpkg -i path/to/on/disk/foobar.deb` gives that error as well? | 18:11 |
| freem | I think dpkg does not give a shit about those signatures, but I might be wrong | 18:12 |
| freem | ah, my bad, a solution was found | 18:14 |
| * freem reads slowly today | 18:14 | |
| rwp | ibanja, AlexLikeRock, I know that one of those syntaxes works to authenticate source repositories but I don't know it myself. I would have to read the docs and try things. | 18:16 |
| rwp | And actually that's been on my list to do because I need it for myself but I don't have the available time to do it today. But it is something like that. | 18:17 |
| rwp | The alternative is one of the older ways of putting the key in /etc/apt/keyrings/something.asc or the other old way of putting it in /etc/apt/trusted.gpg which now generates a warning of obsolescence (which I have been ignoring for a while). | 18:18 |
| AlexLikeRock | ibanja, | 18:21 |
| rwp | systemdlete, cron's @reboot documentation appears to have been dropped in daedalus! | 18:21 |
| AlexLikeRock | heheheh | 18:22 |
| rwp | systemdlete, See the @reboot entries documented in Unstable's man page: https://manpages.debian.org/unstable/systemd-cron/crontab.5.en.html | 18:22 |
| ibanja | rwp: `dpkg -i path/to/on/disk/foobar.deb` does not give an error. I have to update my other computers now and I am doing it with a repo.deb package that I download with wget and install with 'dpkg -i' | 18:26 |
| ibanja | thought you might like to know. | 18:26 |
| rwp | dpkg assumes that files you explicitly tell it to install are trusted. apt does the same. | 18:27 |
| rwp | Also if the .deb includes dependencies that must be installed then if using apt to install the path to the .deb it will install dependencies. Previously one would run dpkg -i first then follow with an "apt-get install -f" to install any missing dependencies. | 18:28 |
| rwp | The trust database comes into play when apt tools are downloading debs from the network. After the deb has already been downloaded by any method then it's a local file and local files are past the trust check. | 18:29 |
| systemdlete | rwp: I noticed that also. Seems these extensions are being dropped all over the place--openwrt's crontab (which is really busybox) only supports some of these @ extensions | 18:31 |
| rwp | I am not sure what's going on with the man page for "man 5 crontab" but in Stable it is quite a different man page. But my Unstable system has it. | 18:32 |
| systemdlete | I think it might be related to the anacron software--I think the cron files are read in every minute and the notion of "@reboot" e.g. would be meaningless by the time it is encountered. | 18:32 |
| rwp | I am using the feature on Devuan 3 Chimaera and positive it works there. And also on Unstable. But I don't actually have it running on a Stable machine. I must test that because I was hoping to upgrade that one soon and I use that feature there. | 18:32 |
| rwp | I purge anacron on non-mobile devices. Laptops suspend and resume and anacron is useful there. But machines that never suspend don't need anacron and I purge it from teh.m | 18:33 |
| systemdlete | that /etc/boot.d thingy won't work for me--it comes too late in the startup sequence. I want to call logrotate before rsyslog starts | 18:33 |
| systemdlete | thanks for confirming all of this--good info | 18:34 |
| rwp | I really, really wish they had named /etc/bood.d /etc/rc.local.d/ instead since that would have followed the naming convention. It's just annoying that /etc/boot.d/ is uniquely unique. | 18:35 |
| systemdlete | I could modify the rsyslog init script, but I hate doing things like that--changes can get lost that way (upgrades) | 18:35 |
| systemdlete | and there doesn't seem to be a /etc/default/rsyslog config file | 18:35 |
| rwp | Why do you want to rotate the syslog files at boot time? They are already rotated daily. (There have been bugs introduced by the systemd folks into the daily rotations.) | 18:36 |
| systemdlete | (although maybe I just haven't looked hard enough) | 18:36 |
| systemdlete | rwp: I have a system that crashes intermittently. It would be nice to be able to spot the ends of all the logs just before the crash, rather than trying to "fish" through them upon reboot. | 18:36 |
| systemdlete | that's all. I know it may sound silly, but it would be really convenient until I can figure out what is going on | 18:37 |
| systemdlete | IOW, just trying to make things a little easier on my already-wracked brains | 18:37 |
| systemdlete | (or you can just call me lazy) | 18:37 |
| rwp | It's okay. I often do things with my systems that other people think I shouldn't be doing. | 18:38 |
| rwp | What's wrong with inserting some scripting to do what you want in /etc/default/rsyslog file? | 18:38 |
| systemdlete | So I thought if I could somehow arrange to (SIMPLY) logrotate at boot, before rsyslog starts, that I could kind of "capture" the logs as they looked at the moment of the crash. No guarantees, of course, since the crash might have left the logs directories in disrepair. | 18:38 |
| systemdlete | rwp ^^^ | 18:39 |
| systemdlete | <systemdlete> I could modify the rsyslog init script, but I hate doing things like that--changes can get lost that way (upgrades) | 18:39 |
| rwp | The /etc/default/rsyslog file will be sourced into the /etc/init.d/rsyslog init script. You should check that it is start when doing your custom action there. | 18:40 |
| systemdlete | and I don't even see such a file there | 18:40 |
| systemdlete | If that is the case, it might work. It would need to be at the START of the script, though. | 18:40 |
| rwp | Huh? "less +34 /etc/init.d/rsyslog" should show the sourcing of it. | 18:40 |
| rwp | "[ -r /etc/default/$NAME ] && . /etc/default/$NAME" Just create that file and put your scripting there. | 18:41 |
| rwp | Again you will want to check $1 and only do your action if it is "start" and just continue through for other actions. | 18:41 |
| freem | " Previously one would run dpkg -i first then follow with an "apt-get install -f" to install any missing dependencies." yeah, I still use old & reliable stuff, got that habit wired hard, I guess | 18:41 |
| freem | didn't knew that apt can install from local storage though... but that won't change anything, I do NOT trust apt's dependency solver, it tries to brings malwares too often (systemd & friends) | 18:42 |
| systemdlete | rwp: As I said, I didn't see a /etc/default/rsyslog file, so I wasn't at all sure it would be read if it did exist. | 18:42 |
| rwp | As far as your other concern about modifying a /etc/init.d/foo and having it change upon upgrade you can always use dpkg-divert to move it over to the side as foo.real or something and then upgrades will be diverted to foo.real leaving you to use foo without concern about upgrades. I do that type of thing when overriding system things. | 18:42 |
| rwp | systemdlete, There is no /etc/default/rsyslog on a pristine system as it does not need it. That's why if you want it you have to create it. | 18:43 |
| systemdlete | yeah, but will I remember I did that in a year from now? LOL | 18:43 |
| systemdlete | rwp: Already figured that out, yes. | 18:43 |
| systemdlete | But because it WASN'T there, I didn't realize it COULD be there. | 18:43 |
| freem | (still running debian since I need debug symbols and could not find out where devuan stores those of the modified packages, and using the wrong debug symbols will just make me loose my time) | 18:43 |
| rwp | If I am looking to see what diversions I have done I just browse /var/lib/dpkg/diversions and see what is listed there. I usually recognize my own work. | 18:44 |
| systemdlete | I think I'll just do the /etc/default/rsyslog thing. It is the simplest and the least likely I will forget later on. | 18:44 |
| freem | (There have been bugs introduced by the systemd folks into the daily rotations.) | 18:44 |
| freem | lol wat? | 18:44 |
| freem | how would they introduce bugs in rsyslog? Should not they only care about their dumb journald? | 18:45 |
| systemdlete | and away we go... | 18:45 |
| rwp | systemdlete, Have confidence that you can create your own files as needed. :-) | 18:45 |
| systemdlete | rwp: Been bitten by such actions in the past, so, a bit leery. Please understand? | 18:45 |
| systemdlete | The fewer things that could go wrong, the better. So I try hard to stay in my lane with these things. | 18:46 |
| rwp | freem, Let me refresh my memory on it. But they dropped the pidfile from rsyslog which breaks daily log rotation. However I don't remember which versions and which OS distros now. (I work with many.) | 18:46 |
| systemdlete | freem, rwp: Is there hardly anything they haven't broken with their silver bullet? | 18:46 |
| freem | meh, why the heck do they touch other's stuff... | 18:46 |
| freem | systemdlete: that's a very good question. | 18:47 |
| rwp | Okay, here is the scoop. It does not affect Devuan. Devuan does not have the problem. Debian systems without systemd have the problem. Regarding rsyslog logrotate. | 18:48 |
| systemdlete | seems like there is a deep desire by so many out there to destroy everything in sight, just generally speaking. This is why we can't have nice things. | 18:48 |
| * freem never really used rsyslogd, only switched from nothing to svlogd when switching from sysVinit to runit | 18:48 | |
| freem | well... I wish them good luck to destroy the tools I use. Worst case i'll just use the upstream busybox which also provides runit & friends hehe | 18:49 |
| freem | although I need to find a solution for that stupid usrmerge. | 18:49 |
| freem | basically, either I trust stupid changes or I freeze my distro version or I find a sane distro which can affort to not follow that | 18:50 |
| rwp | Debian in /lib/systemd/system/rsyslog.service used by systemd added an rsyslogd option -iNONE to disable creating a /run/rsyslogd.pid and without that file the postrotate action of sending rsyslogd a SIGHUP to reopen the newly rotated log file fails to work and it continues to log to the previous file. | 18:50 |
| freem | that was certainly well thought and well tested before merge | 18:51 |
| rwp | The systemd folks force using systemd to send the SIGHUP to the process running under it's umbrella and the pidfile is not used for systemd. | 18:51 |
| freem | well, ok, but there are *already* options to disable the use of pidfiles in most daemons | 18:52 |
| freem | I know it, because stuff running under runsvdir *also* do not need pid files, and I never had to patch anything to make stuff working | 18:52 |
| rwp | On Debian systems (not Devuan) I sed the /lib/systemd/system/rsyslog.service to /etc/systemd/system/rsyslog.service removing that option if the /etc/systemd/system/rsyslog.service does not exist ensuring that it is locally fixed. | 18:53 |
| freem | also, processes receive SIGHUP? wtf! | 18:53 |
| freem | SIGHUP P1990 Term Hangup detected on controlling terminal or death of controlling process | 18:53 |
| freem | from man-page | 18:53 |
| rwp | freem, I don't understand your indignation at SIGHUP? Why? | 18:54 |
| freem | there (or should) is *no* controlling terminal in the situation of a daemon, and it would be lovely, if systemd would die | 18:54 |
| freem | sorry, shitty ISP is slow as heck those days, several seconds lag even on IRC... | 18:54 |
| rwp | freem, Sending SIGHUP to a daemon has always been the traditional way to tell the daemon to reload itself. It's a convention since forever. | 18:55 |
| freem | rwp: the question is why send SIGHUP when the controlling process did not died and there were never any controlling terminal... | 18:55 |
| freem | ah | 18:55 |
| freem | ok then | 18:55 |
| freem | my bad | 18:55 |
| rwp | For rsyslogd in particular see "man rsyslogd" and then look at the SIGNALS section and see it's description. It's a typical daemon. | 18:56 |
| freem | I know some daemon handles signals in some way, it's not a problem for me. What I think is bad is when someone from a 3rd party project modifies stuff unilatterally | 18:56 |
| freem | some attitude we know have a good name for: systemd. | 18:56 |
| rwp | From the systemd folks perspective they have purged all non-systemd use from the Debian system. When they stand on their front porch and look out over their yard they don't want to see anything that is not a part of systemd. | 18:58 |
| rwp | They see that rsyslogd has a pidfile. They ask themselves, What's that doing there? That's not needed. Not since we pushed out all non-systemd inits. Let's clean that up by removing it. And they add the option and it's now gone. | 18:58 |
| rwp | But anyway that's over there and there is a reason we are here running Devuan. Let's not worry about it further and move on. Or at least I do because I need to be afk for a bit. | 18:59 |
| rwp | BBIAB | 18:59 |
| rwp | Oh, before I step away, I have things misremembered. systemd folks have dropped syslog for journald and that's why they don't care about rsylogd pidfiles. | 19:01 |
| systemdlete | is there a flag or some indicator that an init script is called at boot versus some later time? I am touching a tmp file the first time it runs and then checking to see if it exists upon later invocations. It works fine this way, but if there is a cleaner way, I'd be obliged | 19:06 |
| systemdlete | also, does /var/tmp get cleaned out at boot (like /tmp does)? | 19:08 |
| systemdlete | I've heard it is not reliable, but I may be misinformed | 19:09 |
| freem | the only way to get stuff reliably cleaned at boot is to make the folder a ram-fs | 19:10 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!