Re: Duplicity & /etc/daily.local
On Mon, May 20, 2019 at 11:50:13PM +0200, Noth wrote: > Hi misc@, > > > I'm trying to run daily backups to a sftp server for various VMs and > devices on my network, and want to use /etc/daily.local for this. I'm > calling this script from the daily.local file: > > env 'GNUPG="/usr/local/bin/gpg" PASSPHRASE="mypassword"' > /root/duplicity-hostname.sh > > but unfortunately duplicity can't find gnupg and errors out with this error > message: > > Traceback (innermost last): > File "/usr/local/bin/duplicity", line 1562, in > with_tempdir(main) > File "/usr/local/bin/duplicity", line 1548, in with_tempdir > fn() > File "/usr/local/bin/duplicity", line 1387, in main > action = commandline.ProcessCommandLine(sys.argv[1:]) > File "/usr/local/lib/python2.7/site-packages/duplicity/commandline.py", > line 1088, in ProcessCommandLine > globals.gpg_profile = gpg.GPGProfile() > File "/usr/local/lib/python2.7/site-packages/duplicity/gpg.py", line 92, in > __init__ > self.gpg_version = self.get_gpg_version(globals.gpg_binary) > File "/usr/local/lib/python2.7/site-packages/duplicity/gpg.py", line 107, > in get_gpg_version > res = gnupg.run(["--version"], create_fhs=["stdout"]) > File "/usr/local/lib/python2.7/site-packages/duplicity/gpginterface.py", > line 374, in run > create_fhs, attach_fhs) > File "/usr/local/lib/python2.7/site-packages/duplicity/gpginterface.py", > line 423, in _attach_fork_exec > self._as_child(process, gnupg_commands, args) > File "/usr/local/lib/python2.7/site-packages/duplicity/gpginterface.py", > line 462, in _as_child > os.execvp(command[0], command) > File "/usr/local/lib/python2.7/os.py", line 346, in execvp > _execvpe(file, args) > File "/usr/local/lib/python2.7/os.py", line 382, in _execvpe > func(fullname, *argrest) > OSError: [Errno 2] No such file or directory > > GPGError: failed to determine gnupg version of None from > > > duplicity-hostname.sh content: > > #!/bin/ksh > PASSPHRASE=mypassword > /usr/local/bin/duplicity incremental /var sftp://user@backuphost:/hostname/var > /usr/local/bin/duplicity incremental /etc sftp://user@backuphost:/hostname/etc > /usr/local/bin/duplicity incremental /root > sftp://user@backuphost:/hostname/root > > Can daily.local even handle this or is the environment too limited? > > Cheers, > > Noth > I have the same setup and it failed for me as well. I somehow managed to fix it by setting PATH and also exporting TERM: PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games TERM=xterm export PATH TERM And you should probably also do something like: . /root/.passphrase test -n "$PASSPHRASE" || exit 0 export PASSPHRASE Patrick
Re: Booting octeon in single user mode
Thanks Stuart, this also works well and saves having to mess around with uboot. Cheers, Jordan On 5/7/19 3:58 PM, Stuart Henderson wrote: On 2019-05-07, Jordan Geoghegan wrote: Hi folks, I have an old Edgerouter Lite I set up last year that I've forgotten the passwords for. I know you can boot single user mode on amd64 by typing "boot -s" at the bootloader prompt, but that does not seem to exist on octeon. Any help you guys can provide getting my octeon into single user mode would be much appreciated. Jordan Untested on Octeon, but usually you can Ctrl-\ before it goes multiuser.
Re: Booting octeon in single user mode
Thanks Visa, that did the trick! Sorry for the late reply, just got a chance to look at the machine, and everythings working great now. Jordan On 5/7/19 9:58 AM, Visa Hankala wrote: On Tue, May 07, 2019 at 09:19:05AM -0700, Jordan Geoghegan wrote: I have an old Edgerouter Lite I set up last year that I've forgotten the passwords for. You can reset the passwords by using bsd.rd. Run the upgrader until it has mounted the filesystems and asks "Location of sets?" Type ! and press Return to enter shell, and run "chroot /mnt". After that, you can use passwd(1) as usual.
Re: support new
Hi, Duncan Hart wrote on Tue, May 21, 2019 at 08:27:31PM -0400: > N Secure systems research and development using OpenBSD. > > > 0 > > > C Australia > > > P Victoria > > > T Melbourne > > > Z 3000 > > > O Applied OpenBSD > > > I Duncan Hart > > > M dun...@appliedopenbsd.com > > > U https://www.AppliedOpenBSD.com/ Committed, Ingo
Re: support new
Hello Ingo, how are you? You have a point. I'll go with your suggestion. N Secure systems research and development using OpenBSD. Many thanks --Duncan -- Plain text, 72 characters per line or else -- On Tue, 21 May 2019, Ingo Schwarze wrote: > Hi Duncan, > > Duncan Hart wrote on Sun, May 19, 2019 at 11:57:07PM -0400: > > > 0 > > C Australia > > P Victoria > > T Melbourne > > Z 3000 > > O Applied OpenBSD > > I Duncan Hart > > M dun...@appliedopenbsd.com > > U https://www.AppliedOpenBSD.com/ > > N Applied OpenBSD research and development > > I'm not convinced the last of these lines is appropriate; > does an OpenBSD developer working for AppliedOpenBSD.com > really exist? > > If not, advertising "OpenBSD development" might seem misleading. > In that case, maybe you would like to reword the last line, for > example "research and development using OpenBSD" or "... based on > OpenBSD" or something like that? > > Yours, > Ingo >
Re: single user question
Sorry. Stefan. Batting 1000. -Jim On Tue, May 21, 2019 at 1:20 PM James Huddle wrote: > Just a quick shout-out to Roderick: > Thank you for the paper reference. It's probably perfect for my needs, > but I've been a bit busy, as of late. So no papers, regardless of year > written. > One of my favorite references is Thompson's "Reflections on Trusting Trust" > so I'm hep to your SuperFly-Era ways. No dateism or ageism from this > child of the 60's. > -jrh > > On Fri, May 17, 2019 at 2:36 PM Nathan Hartman > wrote: > >> On Fri, May 17, 2019 at 12:28 PM ropers wrote: >> >> > >> > In the history of the (Berkeley) Fast File System, has there ever been >> > an attempt to implement DOS-like undelete for FFS/UFS? >> > (I understand that for technical reasons, this could require running a >> > daemon that remembers just enough metadata to keep data recoverable so >> > long as it's not overwritten. I also understand that running a daemon >> > that remembers things nominally deleted would have security >> > implications, which may not keep me from running a daemond that w/o >> > being perfect could protect me from myself at least some of the time.) >> > I did find this: >> > >> https://lists.freebsd.org/pipermail/freebsd-questions/2016-May/271785.html >> > -- which didn't seem to suggest that the answer was any yessier now >> > than thirty years ago. So, that's a no, then? Anyone? Bueller? >> >> >> Maybe that could work for "normal delete" while making available a >> separate >> "secure delete" that cannot be un-deleted and furthermore overwrites the >> deleted data with random garbage. Administrators could optionally force >> the >> secure overwrite delete. >> >> > >> >
Re: single user question
Just a quick shout-out to Roderick: Thank you for the paper reference. It's probably perfect for my needs, but I've been a bit busy, as of late. So no papers, regardless of year written. One of my favorite references is Thompson's "Reflections on Trusting Trust" so I'm hep to your SuperFly-Era ways. No dateism or ageism from this child of the 60's. -jrh On Fri, May 17, 2019 at 2:36 PM Nathan Hartman wrote: > On Fri, May 17, 2019 at 12:28 PM ropers wrote: > > > > > In the history of the (Berkeley) Fast File System, has there ever been > > an attempt to implement DOS-like undelete for FFS/UFS? > > (I understand that for technical reasons, this could require running a > > daemon that remembers just enough metadata to keep data recoverable so > > long as it's not overwritten. I also understand that running a daemon > > that remembers things nominally deleted would have security > > implications, which may not keep me from running a daemond that w/o > > being perfect could protect me from myself at least some of the time.) > > I did find this: > > > https://lists.freebsd.org/pipermail/freebsd-questions/2016-May/271785.html > > -- which didn't seem to suggest that the answer was any yessier now > > than thirty years ago. So, that's a no, then? Anyone? Bueller? > > > Maybe that could work for "normal delete" while making available a separate > "secure delete" that cannot be un-deleted and furthermore overwrites the > deleted data with random garbage. Administrators could optionally force the > secure overwrite delete. > > > >
Re: Duplicity & /etc/daily.local
Hi Noth, On Mon, 20 May 2019 23:50:13 +0200 Noth wrote: > /root/duplicity-hostname.sh Does this script work properly when you're logged in as root? > > #!/bin/ksh > PASSPHRASE=mypassword try: export PASSPHRASE='mypassword' > Can daily.local even handle this or is the environment too limited? daily is run by root's crontab. To get root's cron environment mailed out, add a temp root cron job: [next 5 mins] [this hour] * * * logname; umask; pwd; printenv | sort If your script works well when logged in as root, but not from cron, add the missing environment elements to daily.local/script/root's crontab. Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
Re: ffs undelete was: Re: single user question
Hi, Edgar Pettijohn wrote on Fri, May 17, 2019 at 03:47:41PM -0500: > On 5/17/19 2:34 PM, Nathan Hartman wrote: >> In the history of the (Berkeley) Fast File System, has there ever >> been an attempt to implement DOS-like undelete for FFS/UFS? >> >> Maybe that could work for "normal delete" while making available a >> separate "secure delete" that cannot be un-deleted [...] Hell no. That is absolutely not wanted. It's actually one of the (many) advantages of UNIX over DOS that commands really do what they promise, taking the user seriously and not trying to second-guess them or try to be their nanny: rm(1) means remove. Period. Anything else would just be plain silly. > I'm thinking something like a trashcan. Where rm(1) actually just > moves the files to some predetermined location then on shutdown > all files older than some configureable date are actually unlinked. What an abominable, misguided idea. If you want mv(1), don't use rm(1). Just use mv(1), dammit! And if you want /tmp, simply use /tmp... The answer is really as simple as that. Yours, Ingo
tmux configs
Hi all I'm modifying the tmux config parser and I need configs for testing, if you have an interesting .tmux.conf (ie more than just a few set/bind lines) then please email it to me privately. If you want it to be kept private please mention that in the email. Thanks
Re: malloc_conf J j
Hi Jan, Jan Stary wrote on Sun, May 19, 2019 at 05:46:08PM +0200: > On May 19 16:46:44, schwa...@usta.de wrote: >> Jan Stary wrote: >>> The current "increase/decrease" wording in malloc(3) >>> can suggest it has a memory. For example, setting >>> >>> vm.malloc_conf=J >>> >>> "increases" junk level to two; >>> does setting >>> >>> vm.malloc_conf=C >>> >>> later retain a junk level of two, >>> as there is no 'j' to "decrease" it, >>> or is the junk level the defult of one now? >> Your question makes no sense whatsoever. >> First, the word "later" makes no sense. > I should have worded more clearly. I meant programs that start later, Oh. It didn't even occur to me that somebody could possibly fall prey to the misconception that anything related to a library function that is not a system call could possibly propagate from one process to another process that isn't even a child of the first one. I think the fact that we are in section 3 here and not in section 2 already makes it clear enough that whatever is described here starts from scratch for every new process and cannot depend on whatever other processes may have done before. > after vm.malloc_conf is set to something else. Well, sysctl(2) tells you that vm.malloc_conf is a *string*, so it is already clear enough that the kernel does *not* store junk levels as numbers but simply stores a string of letters. So it should be clear that first setting one string, then another one overrides the first string and can in no way be cumulative. > It makes perfect sense now, thanks. I agree nothing more seems to be missing from the documentation; at least, i don't see what might still be missing. Yours, Ingo
Re: support new
Hi Duncan, Duncan Hart wrote on Sun, May 19, 2019 at 11:57:07PM -0400: > 0 > C Australia > P Victoria > T Melbourne > Z 3000 > O Applied OpenBSD > I Duncan Hart > M dun...@appliedopenbsd.com > U https://www.AppliedOpenBSD.com/ > N Applied OpenBSD research and development I'm not convinced the last of these lines is appropriate; does an OpenBSD developer working for AppliedOpenBSD.com really exist? If not, advertising "OpenBSD development" might seem misleading. In that case, maybe you would like to reword the last line, for example "research and development using OpenBSD" or "... based on OpenBSD" or something like that? Yours, Ingo
Re: Duplicity & /etc/daily.local
On Mon, May 20, 2019 at 11:50:13PM +0200, Noth wrote:
> Hi misc@,
>
>
> I'm trying to run daily backups to a sftp server for various VMs and
> devices on my network, and want to use /etc/daily.local for this. I'm
> calling this script from the daily.local file:
>
> env 'GNUPG="/usr/local/bin/gpg" PASSPHRASE="mypassword"'
> /root/duplicity-hostname.sh
>
> but unfortunately duplicity can't find gnupg and errors out with this error
> message:
>
> Traceback (innermost last):
> File "/usr/local/bin/duplicity", line 1562, in
> with_tempdir(main)
> File "/usr/local/bin/duplicity", line 1548, in with_tempdir
> fn()
> File "/usr/local/bin/duplicity", line 1387, in main
> action = commandline.ProcessCommandLine(sys.argv[1:])
> File "/usr/local/lib/python2.7/site-packages/duplicity/commandline.py",
> line 1088, in ProcessCommandLine
> globals.gpg_profile = gpg.GPGProfile()
> File "/usr/local/lib/python2.7/site-packages/duplicity/gpg.py", line 92, in
> __init__
> self.gpg_version = self.get_gpg_version(globals.gpg_binary)
> File "/usr/local/lib/python2.7/site-packages/duplicity/gpg.py", line 107,
> in get_gpg_version
> res = gnupg.run(["--version"], create_fhs=["stdout"])
> File "/usr/local/lib/python2.7/site-packages/duplicity/gpginterface.py",
> line 374, in run
> create_fhs, attach_fhs)
> File "/usr/local/lib/python2.7/site-packages/duplicity/gpginterface.py",
> line 423, in _attach_fork_exec
> self._as_child(process, gnupg_commands, args)
> File "/usr/local/lib/python2.7/site-packages/duplicity/gpginterface.py",
> line 462, in _as_child
> os.execvp(command[0], command)
> File "/usr/local/lib/python2.7/os.py", line 346, in execvp
> _execvpe(file, args)
> File "/usr/local/lib/python2.7/os.py", line 382, in _execvpe
> func(fullname, *argrest)
> OSError: [Errno 2] No such file or directory
>
> GPGError: failed to determine gnupg version of None from
>
>
> duplicity-hostname.sh content:
>
> #!/bin/ksh
> PASSPHRASE=mypassword
> /usr/local/bin/duplicity incremental /var sftp://user@backuphost:/hostname/var
> /usr/local/bin/duplicity incremental /etc sftp://user@backuphost:/hostname/etc
> /usr/local/bin/duplicity incremental /root
> sftp://user@backuphost:/hostname/root
>
> Can daily.local even handle this or is the environment too limited?
daily.local is run by cron which sets:
PATH=/bin:/sbin:/usr/bin:/usr/sbin
Try setting this in your script:
PATH=${PATH}:/usr/local/bin
--
Antoine
