Re: Backup of OpenBSD to Linux box
2015-06-15 8:46 GMT+02:00 Bernd Schoeller : > Hi - > > I have got an OpenBSD box, and I would like to create regular full backups > of that box to a Linux server at a different location. > > The main purpose of this backup is to be able to restore the OpenBSD box on > a severe hardware failure (HD corruption, fire, etc.). If possible, the > backup should be incremental as I am somewhat bandwidth constrained between > the two sites. > > There are a number of remote backup systems floating around (rdiff-backup, > rsnapshot, etc.) and of course there are in-house solutions (dump/restore), > though I don't know if these are interoperable. > > Is there somebody on the list who has a similar setup and could point me at > a solution that works for him/her? > > Thanks, > Bernd > You should have a look at `man 8 dump`. -- Cordialement, Coues Ludovic +336 148 743 42
Backup of OpenBSD to Linux box
Hi - I have got an OpenBSD box, and I would like to create regular full backups of that box to a Linux server at a different location. The main purpose of this backup is to be able to restore the OpenBSD box on a severe hardware failure (HD corruption, fire, etc.). If possible, the backup should be incremental as I am somewhat bandwidth constrained between the two sites. There are a number of remote backup systems floating around (rdiff-backup, rsnapshot, etc.) and of course there are in-house solutions (dump/restore), though I don't know if these are interoperable. Is there somebody on the list who has a similar setup and could point me at a solution that works for him/her? Thanks, Bernd
Re: GROUP CHANGED
> > Yes, it was on the su(1) man page...it's still in their docs: > > > > http://www.gnu.org/software/coreutils/manual/html_node/su-invocation.html#index-fascism-2365 > > > > So welcome to the oppressive, totalitarian regime of *BSD. If you've got > > root, be sure to claim your free pair of hobnailed boots to place on the > > necks of your users. CEMENT THE POWER! > > This is all you need to know; > "(This section is by Richard Stallman.)" > > Or, "Warning; delusional nut job about to pontificate." Well there is this funny story about when I hacked into RMS's firmware-driven keyboard controller, and managed to grap his root password. Later there was another user (who obviously should never have root), but since there was no wheel group.
Re: GROUP CHANGED
On Sun, Jun 14, 2015, at 06:14 PM, andrew fabbro wrote: > On Sun, Jun 14, 2015 at 10:17 AM, Marc Espie wrote: > > > Note that the description of "wheel" characteristics > > in FSF's Linux used to be hilarious. > > > > Yes, it was on the su(1) man page...it's still in their docs: > > http://www.gnu.org/software/coreutils/manual/html_node/su-invocation.html#index-fascism-2365 > > So welcome to the oppressive, totalitarian regime of *BSD. If you've got > root, be sure to claim your free pair of hobnailed boots to place on the > necks of your users. CEMENT THE POWER! This is all you need to know; "(This section is by Richard Stallman.)" Or, "Warning; delusional nut job about to pontificate."
Re: GROUP CHANGED
My memories of Debiandora are fading slightly, but, ... 2015/06/15 8:53 "Rick Hanson" : > > From the linux su man page: > > > This version of su uses PAM for authentication, account and session > > management. Some configuration options found in other su > > implementations, such as support for a wheel group, have to be > > configured via PAM. > > So, you see, the jack-booted thug "rulers" have already "cement[ed] > the[ir] power" in GNU/Linux. O Freedom! We knew ye not as our > fathers did, who roamed without fetters on the Twenex fields of yore! > ;) > > On Sun, Jun 14, 2015 at 6:14 PM, andrew fabbro wrote: > > > > Yes, it was on the su(1) man page...it's still in their docs: > > > > http://www.gnu.org/software/coreutils/manual/html_node/su-invocation.html#index-fascism-2365 > > > > So welcome to the oppressive, totalitarian regime of *BSD. If you've got > > root, be sure to claim your free pair of hobnailed boots to place on the > > necks of your users. CEMENT THE POWER! ... I think the numeric id for wheel group in Linux is not 0. Which is relevant to the OP's misplaced concerns. (Not to mention the topic of power grabs.)
Re: GROUP CHANGED
>From the linux su man page: > This version of su uses PAM for authentication, account and session > management. Some configuration options found in other su > implementations, such as support for a wheel group, have to be > configured via PAM. So, you see, the jack-booted thug "rulers" have already "cement[ed] the[ir] power" in GNU/Linux. O Freedom! We knew ye not as our fathers did, who roamed without fetters on the Twenex fields of yore! ;) On Sun, Jun 14, 2015 at 6:14 PM, andrew fabbro wrote: > > Yes, it was on the su(1) man page...it's still in their docs: > > http://www.gnu.org/software/coreutils/manual/html_node/su-invocation.html#index-fascism-2365 > > So welcome to the oppressive, totalitarian regime of *BSD. If you've got > root, be sure to claim your free pair of hobnailed boots to place on the > necks of your users. CEMENT THE POWER! > > -- > andrew fabbro > and...@fabbro.org > blog: https://raindog308.com
Re: sogo, httpd(8) and the rewrite need
> On 14.06.2015, at 18:08, Joel Carnat wrote:
>
> Hi,
>
> I was going to install SOGo on OpenBSD 5.7 using the native httpd(8).
> In the readme, there are configuration examples for nginx and
> apache-httpd-openbsd. Nothing for the new httpd.
> There are rewrite/redirect features that I can’t figure out how to setup with
> httpd(8).
>
> nginx example:
>location = /principals/
>{
>rewrite ^ http://$server_name/SOGo/dav;
>allow all;
>}
>
> apache-httpd-openbsd example:
> RedirectMatch ^/principals/$ http://127.0.0.1:8800/SOGo/dav/
>
> Is it possible to achieve such feature with httpd and/or relayd ?
>
Kind of. You could try something like:
location "/principals/" {
block return 301 "http://$SERVER_NAME/SOGo/dav/";
}
Replace $SERVER_NAME with the IP, or add $SERVER_PORT, if required.
Reyk
Re: GROUP CHANGED
On Sun, Jun 14, 2015 at 10:17 AM, Marc Espie wrote: > Note that the description of "wheel" characteristics > in FSF's Linux used to be hilarious. > Yes, it was on the su(1) man page...it's still in their docs: http://www.gnu.org/software/coreutils/manual/html_node/su-invocation.html#index-fascism-2365 So welcome to the oppressive, totalitarian regime of *BSD. If you've got root, be sure to claim your free pair of hobnailed boots to place on the necks of your users. CEMENT THE POWER! -- andrew fabbro and...@fabbro.org blog: https://raindog308.com
sogo, httpd(8) and the rewrite need
Hi,
I was going to install SOGo on OpenBSD 5.7 using the native httpd(8).
In the readme, there are configuration examples for nginx and
apache-httpd-openbsd. Nothing for the new httpd.
There are rewrite/redirect features that I can’t figure out how to setup with
httpd(8).
nginx example:
location = /principals/
{
rewrite ^ http://$server_name/SOGo/dav;
allow all;
}
apache-httpd-openbsd example:
RedirectMatch ^/principals/$ http://127.0.0.1:8800/SOGo/dav/
Is it possible to achieve such feature with httpd and/or relayd ?
Thanks.
Re: Major improvement in CPU temperatures for -current
thinkpad x60s here, copying 130G from one encrypted softraid to another one: 86-89C down to 71-74C. now i need to buy an extra heater :( this is some great news for my testies, our great thanks in the name of the whole family :) -f -- one family builds a wall, two families enjoy it.
Re: partition alignment and advanced format drives
Theo de Raadt, 14 Jun 2015 12:15: > > some modern linux distros (and win7) use 2048 sectors > > as offset for their first partition, an alignment of > > 1MB. openbsd's fdisk uses 64. one thing it does not > > do is creating partition sizes divisble > > you have confused yourself. my mistake here, that was an unfinished train of thought that i moved to the bottom of the email and forgot to delete here. sorry about that. i did not mean to imply openbsd is doing anything wrong. quite the contrary. > > 3. non-aligned > > offset: [63] > > 339.51 real 4.46 user 5.63 sys > > > > quite a difference. > > Quite a difference WHAT?? Noone uses a non-pow2 alignment. Everyone > aligns -- everyone, except you, in this bogus test. This is not a > matter of science. Your message is very confusing since the length of > it subtly hints OpenBSD is doing something wrong, and we are not. yes, i can see how you came to that conclusion me forgetting to delete that half sentence up there. but it is exactly the contrary. the whole point of this email was to show how fdisk is doing the correct thing, and that there is no difference performance-wise between 64 and 2048 sector offsets. the misaligned partition example was simply to see the hard drive firmware in action on non-aligned partitions. i used openbsd's fdisk to set up this non-aligment, but i did not mean to imply that fdisk is doing something wrong. i did not include all the commands because it would have made the mail excessively long, but it would have shown clearly that by default fdisk will not create misaligned partitions. again, my mistake. > > one thing fdisk does not seem to do yet: > > > > generate partition sizes divisible by 8. > > while maybe not necessary on an openbsd only system, > > in multiboot configurations it might be a matter > > of being a good neighbour in cases where openbsd > > is not the last partition on the disk. > > So you are the one concerned about this. And you already have a setup > to test with. So why don't you try writing a diff -- instead of > trying to pawn your problem off on someone else? i wasn't trying to pawn my problems on others, but it is true that i am floating this idea around, becasue so far i have not seen any discussion about the merit of this idea. -f -- a true friend knows who you are... but likes you anyway.
Re: partition alignment and advanced format drives
> i got curious how visible this speed difference would > be, so while i was setting up the disk anyway, i made > this unscientific experiment. > > some modern linux distros (and win7) use 2048 sectors > as offset for their first partition, an alignment of > 1MB. openbsd's fdisk uses 64. one thing it does not > do is creating partition sizes divisble you have confused yourself. > 1. openbsd default > offset: [64] > 280.28 real 6.32 user 7.59 sys > 2. linux style > offset: [2048] > 280.78 real 6.99 user 6.01 sys So no difference at all between those two. > 3. non-aligned > offset: [63] > 339.51 real 4.46 user 5.63 sys > quite a difference. Quite a difference WHAT?? Noone uses a non-pow2 alignment. Everyone aligns -- everyone, except you, in this bogus test. This is not a matter of science. Your message is very confusing since the length of it subtly hints OpenBSD is doing something wrong, and we are not. > one thing fdisk does not seem to do yet: > > generate partition sizes divisible by 8. > while maybe not necessary on an openbsd only system, > in multiboot configurations it might be a matter > of being a good neighbour in cases where openbsd > is not the last partition on the disk. So you are the one concerned about this. And you already have a setup to test with. So why don't you try writing a diff -- instead of trying to pawn your problem off on someone else?
partition alignment and advanced format drives
i was putting a 2.5" 500G WD disk into a usb enclosure and i noticed that instead of technical information they used to put there (chs, lba, etc) most of the space was taken up by a notice about this being "advenced format drive", and how speed will suffer if used with windows xp, etc, without partition realignment. and it had jumpers -- i haven't seen jumpers on drives for ages. IIUC, the jumpers can be used to indicate an "offset-by-one": make LBA 63 aligned on hardware sector. quite the backwards compatibility. i got curious how visible this speed difference would be, so while i was setting up the disk anyway, i made this unscientific experiment. some modern linux distros (and win7) use 2048 sectors as offset for their first partition, an alignment of 1MB. openbsd's fdisk uses 64. one thing it does not do is creating partition sizes divisble 1. openbsd default Disk: sd3 geometry: 60801/255/63 [976773168 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 60800 254 63 [ 64: 976768001 ] OpenBSD partition: [a] offset: [64] size: [976768001] FS type: [4.2BSD] Rounding size to bsize (64 sectors): 976768000 # time newfs /dev/rsd3a /dev/rsd3a: 476937.5MB in 976768000 sectors of 512 bytes 586 cylinder groups of 814.44MB, 26062 blocks, 52224 inodes each super-block backups (for fsck -b #) at: ... 972425408, 974093376, 975761344, 280.28 real 6.32 user 7.59 sys 2. linux style Disk: sd3 geometry: 60801/255/63 [976773168 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 32 33 - 60800 254 63 [2048: 976766017 ] OpenBSD partition: [a] offset: [2048] size: [976766017] FS type: [4.2BSD] Rounding size to bsize (64 sectors): 976766016 # time newfs /dev/rsd3a /dev/rsd3a: 476936.5MB in 976766016 sectors of 512 bytes 586 cylinder groups of 814.44MB, 26062 blocks, 52224 inodes each super-block backups (for fsck -b #) at: ... 972425408, 974093376, 975761344, 280.78 real 6.99 user 6.01 sys 3. non-aligned Disk: sd3 geometry: 60801/255/63 [976773168 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 1 - 60800 254 63 [ 63: 976768002 ] OpenBSD partition: [a] offset: [63] size: [976768002] FS type: [4.2BSD] Rounding size to bsize (64 sectors): 976768001 # time newfs /dev/rsd3a /dev/rsd3a: 476937.5MB in 976768000 sectors of 512 bytes 586 cylinder groups of 814.44MB, 26062 blocks, 52224 inodes each super-block backups (for fsck -b #) at: ... 972425408, 974093376, 975761344, 339.51 real 4.46 user 5.63 sys quite a difference. one thing fdisk does not seem to do yet: generate partition sizes divisible by 8. while maybe not necessary on an openbsd only system, in multiboot configurations it might be a matter of being a good neighbour in cases where openbsd is not the last partition on the disk. -f -- i'm so close to hell i can almost see vegas!
Re: GROUP CHANGED
On Sun, Jun 14, 2015 at 04:46:53PM +0200, Max Power wrote: > Thank You Gilles for Your reply. > > Only the group is changed. > But why the owner is remained the same [root]? > On OpenBSD, I can not get root:root ? Tradition. Note that the description of "wheel" characteristics in FSF's Linux used to be hilarious.
Re: Major improvement in CPU temperatures for -current
Can confirm this. Quite a significant change on my Thinkpad X220. Thanks a lot!
Re: GROUP CHANGED
Groups and users are actually just numbers, the mapping to names happens in the /etc/passwd and /etc/group files. On Linux, user 0 is 'root' and group 0 is 'root'. On BSDs, user 0 is 'root', but group 0 is 'wheel'. Check the /etc/group file on both systems, and you will see. Bernd On 14/06/15 15:46, Max Power wrote: > Thank You Gilles for Your reply. > > Only the group is changed. > But why the owner is remained the same [root]? > On OpenBSD, I can not get root:root ? > > Thanks. > >> On Sun, Jun 14, 2015 at 04:32:18PM +0200, Max Power wrote: >>> Hi guys! >>> >>> I copied my files from Debian [ext4] to my new server OpenBSD [5.7 >>> amd64], >>> and I found that all files of 'ROOT' group were imported [in OpenBSD] in >>> the 'Wheel' group. >>> Why is this? >>> >>> [Owner is the same, there is no change.] >>> >>> Thank fro reply. >>> >> >> wheel is the new root. >> >> https://en.wikipedia.org/wiki/Wheel_(Unix_term) >> >> -- >> Gilles Chehade >> >> https://www.poolp.org @poolpOrg
Re: sh(1), ksh(1) - lack of information about default sourcefile.
El Sun, 14 Jun 2015 16:19:58 +0100, Maurice McCarthy escribió: > The file itself says it is for default for root. My bad, that is true. An user here had noticed that some shell variables existed in his shell even if no /etc/profile nor ~/.profile (nor other files listed in sh(1) and ksh(1)) existed. We wondered where the defaults came from and we only could find the /.profile file (which, as you have pointed, is not the source of these variables). Some further investigation suggest these variables could come from /etc/ login.conf.
Re: sh(1), ksh(1) - lack of information about default sourcefile.
On Sun, Jun 14, 2015 at 02:48:17PM + or thereabouts, Black Rider wrote:
> Hello.
>
> I have noticed that the ksh and sh manpages don't make reference to the
> file /.profile, which I understand to hold the default shell variables if
> the other source files listed on the manuals don't exist.
>
The file itself says it is for default for root.
$ cat /.profile
# $OpenBSD: dot.profile,v 1.9 2010/12/13 12:54:31 millert Exp $
#
# sh/ksh initialization
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
export PATH
: ${HOME='/root'}
export HOME
umask 022
case "$-" in
*i*)# interactive shell
if [ -x /usr/bin/tset ]; then
if [ X"$XTERM_VERSION" = X"" ]; then
eval `/usr/bin/tset -sQ '-munknown:?vt220' $TERM`
else
eval `/usr/bin/tset -IsQ '-munknown:?vt220' $TERM`
fi
fi
;;
esac
sh(1), ksh(1) - lack of information about default sourcefile.
Hello. I have noticed that the ksh and sh manpages don't make reference to the file /.profile, which I understand to hold the default shell variables if the other source files listed on the manuals don't exist. The current FILES secion of SH(1): FILES ~/.profile User's login profile. /etc/profile System login profile. /etc/suid_profilePrivileged shell profile. /etc/shells Shell database. The current FILES section of KSH(1) FILES ~/.profile User's login profile. /etc/ksh.kshrc Global configuration file. Not sourced by default. /etc/profile System login profile. /etc/shells Shell database. /etc/suid_profilePrivileged shell profile. I noticed that when none of this files exist, variables for the shells are populated from somewhere else. (/.profile). My suggestion is to update the docummentation, and add /.profile to the FILES section of the man pages. Or just move /.profile to /etc/profile if feasible. Is there any reason for having a configuration dotfile in / ?
Re: GROUP CHANGED
On 2015-06-14 16.46.53 +0200, Max Power wrote: > Only the group is changed. > But why the owner is remained the same [root]? > On OpenBSD, I can not get root:root ? No: $ grep ^root /etc/group $ > > On Sun, Jun 14, 2015 at 04:32:18PM +0200, Max Power wrote: > >> Hi guys! > >> > >> I copied my files from Debian [ext4] to my new server OpenBSD [5.7 > >> amd64], > >> and I found that all files of 'ROOT' group were imported [in OpenBSD] in > >> the 'Wheel' group. > >> Why is this? > >> > >> [Owner is the same, there is no change.] > >> > >> Thank fro reply. > >> > > > > wheel is the new root. > > > > https://en.wikipedia.org/wiki/Wheel_(Unix_term) > > > > -- > > Gilles Chehade > > > > https://www.poolp.org @poolpOrg
GROUP CHANGED
Thank You Gilles for Your reply. Only the group is changed. But why the owner is remained the same [root]? On OpenBSD, I can not get root:root ? Thanks. > On Sun, Jun 14, 2015 at 04:32:18PM +0200, Max Power wrote: >> Hi guys! >> >> I copied my files from Debian [ext4] to my new server OpenBSD [5.7 >> amd64], >> and I found that all files of 'ROOT' group were imported [in OpenBSD] in >> the 'Wheel' group. >> Why is this? >> >> [Owner is the same, there is no change.] >> >> Thank fro reply. >> > > wheel is the new root. > > https://en.wikipedia.org/wiki/Wheel_(Unix_term) > > -- > Gilles Chehade > > https://www.poolp.org @poolpOrg
Re: GROUP CHANGED
On Sun, Jun 14, 2015 at 04:32:18PM +0200, Max Power wrote: > Hi guys! > > I copied my files from Debian [ext4] to my new server OpenBSD [5.7 amd64], > and I found that all files of 'ROOT' group were imported [in OpenBSD] in > the 'Wheel' group. > Why is this? > > [Owner is the same, there is no change.] > > Thank fro reply. > wheel is the new root. https://en.wikipedia.org/wiki/Wheel_(Unix_term) -- Gilles Chehade https://www.poolp.org @poolpOrg
GROUP CHANGED
Hi guys! I copied my files from Debian [ext4] to my new server OpenBSD [5.7 amd64], and I found that all files of 'ROOT' group were imported [in OpenBSD] in the 'Wheel' group. Why is this? [Owner is the same, there is no change.] Thank fro reply.
enabling GPT (was Re: what to do with a uefi hp pavillion 10-f014au?)
David Coppa suggests a custom kernel with the GPT option turned on. I'm thinking along the lines of (1) compiling the custom kernels (GENERIC, GENERIC.MP, and RAMDISK with the option GPT turned on) and (2) making a bootable USB drive with that, (3) backing up the current installed openbsd system to another USB drive, probably a USB connected rotating HD. (4) then resurrecting MSWindows from the recovery disks and shrinking the MSWindows partition, and (5) using the USB drive to try installing to a GPT partition. What else would I need besides building the GPT enabled kernel? Do I need to install additional packages, or apply the google soc diffs as patches to things? And what kind of odds do I have of being able to dual-boot (using the BIOS boot manager, I suppose) openbsd on such a system? On Wed, May 20, 2015 at 5:28 PM, David Coppa wrote: > On Wed, May 20, 2015 at 9:00 AM, Joel Rees wrote: >> besides take it back to the store, I mean. >> >> I have it booted on a USB stick. The internal drive appears to be >> unpartitioned when I do a disklabel -- only c partition reported. fdisk >> does report it as EFI GPT. >> >> I read something about support in the kernel. Is there any hope of say, >> constructing a disklabel by hand and copying the file system over by hand? >> (I have opened up an empty "simple" partition on the disk already.) > > You could try with a custom kernel compiled with the GPT option turned on. > GPT support is currently commented out (see > src/sys/arch/amd64/conf/GENERIC), but it may work... > > Ciao, > David > -- > "If you try a few times and give up, you'll never get there. But if > you keep at it... There's a lot of problems in the world which can > really be solved by applying two or three times the persistence that > other people will." > -- Stewart Nelson -- Joel Rees Be careful when you look at conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself, as well.
Re: Blob-free OpenBSD kernel needed
On Sat, Jun 13, 2015 at 11:54:27PM +, Stuart Henderson wrote: > On 2015-06-06, Артур Истомин wrote: > > Your rant is cogent. But if so, why OpenBSD does not supply > > microcode updates from Intel/AMD? There are tons of security fixes. > > Isn't that the bios's area? (don't run libreboot if you want those...) Yes it is. But BIOS update is like SOHO routers' firmware updates They are either non-existent or issued short time (year or two). By the way, I've never seen mention of the CPU's microcode updates in BIOS updates' changelogs (if they, changelogs, exist at all). In fact, all I wanted was to get an authoritative answer why OpenBSD does not supply CPU's microcode updates. I suspect it is not in priority list, but may be there is more tricky/interesting reason! ...but even Ted Unangst (second in thread and exactly after my answer why not!) offers to send him patches with free microcodes, what the stupid idiots..
Re: Blob-free OpenBSD kernel needed
On Sat, Jun 13, 2015 at 06:01:53PM -0400, Ted Unangst wrote: > Артур Истомин wrote: > > Your rant is cogent. But if so, why OpenBSD does not supply > > microcode updates from Intel/AMD? There are tons of security fixes. > > Are they free? Send a patch. Don't be so lame before answering, open my next email, there is double "patch": for your stupid answer and for your idiotic behavior in correspondence.
Re: Blob-free OpenBSD kernel needed
I got the idea of this post, finally: one guy lacking basic knowledge pops in and talks in confusion about some non-free parts inside OpenBSD's kernel. Few threads more and another one is posting a suggestion of liberation. Cheap ads. I am convinced now the "free" idea got distorted reaching the boundary of paranoia. For the OP: Was openssl able to satisfy you because it was free, open, source code available, GPL sexy version on? Was it free of bugs, trojans, backdoors, etc? A time will come when folks will appreciate quality code and people behind it. Nah, I really don't think so!
