Re: .profile not being loaded (ksh) when opening shell in X
On Tue, 2021-04-27 at 09:37 +0200, Alexandre Ratchov wrote: > If you're using a display manager (xenodm or whatever), you've to > include your .profile in your session login script (X equivalent of > shell's ~/.profile concept), so the envoronment (and other global > login settings) from your .profile become visible to all X programs, > not only xterm. For instance put: > > . ~/.profile I noticed the effect that the OP described ($PWD and $HOME/.profile being ignored) too, when I reinstalled all packages (due to /usr/local partition going foobar) and also switched to Mate a couple of weeks ago. Happens both in mate-terminal and in xterm. Unfortunately tricks like described above didn't help. I think, I also tried Xfce and had the same effect, not sure though. Strangely, if I open a new mate-terminal, $PWD and .profile are ignored; If I open the second tab, they are processed, though ... So I guess the next step is to upgrade to todays snap and test, I it stays the same, and wheter I may reproduce it with a more basic WM like CWM/FVWM ...
Re: .profile not being loaded (ksh) when opening shell in X
Stuart Henderson writes: > Seems that your terminal in X is not configured to run a login shell. > By default that is done for xterm via .Xdefaults in a new user's profile > directory (copied from /etc/skel) but if you use a different terminal > or have modified these files, that won't be used. With the caveat that I have not perused all possibly relevant configs on my system, my install is fairly standard and my ~/.Xdefaults file has: ! $OpenBSD: dot.Xdefaults,v 1.3 2014/07/10 10:22:59 jasper Exp $ XTerm*loginShell:true Yet if I run an xterm from my window manager (aweswome) it does not read my ~/.profile. I worked around this by using the '-ls' argument to xterm, but maybe that's hiding the real reason this is happening. I have not tried any other window managers. For good measure, here is my ~/.xsession: xrdb -merge ~/.Xresources xset +fp /usr/local/share/fonts/Liberation,/usr/local/share/fonts/ghostscript,/usr/local/share/fonts/cantarell,/usr/local/share/fonts/noto autocutsel -fork & autocutsel -selection PRIMARY -fork & xset mouse 4/1 4 xset r rate 200 50 exec awesome Allan
Re: Remote wipe software
Oliver Leaver-Smith said on Tue, 27 Apr 2021 13:19:21 +0100 >Thanks for your response, a lot to think about sure. I suppose having >some sort of phone home daemon running to know whether or not to dd >itself is probably the best way to at least somewhat destroy itself in >a disaster scenario If you employ a dead man's switch like you describe above, you really should back up that machine every single day. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Re: .profile not being loaded (ksh) when opening shell in X
On Tue, Apr 27, 2021 at 09:37:05AM +0200, Alexandre Ratchov wrote: If you're using a display manager (xenodm or whatever), you've to include your .profile in your session login script (X equivalent of shell's ~/.profile concept), so the envoronment (and other global login settings) from your .profile become visible to all X programs, not only xterm. For instance put: . ~/.profile at the beginning of our ~/.xsession If you're using xinit(1), your ~/.profile is already loaded by the login shell. That seems the right way to go, if the other suggested solution of defining ENV doesn't do the trick.
Re: .profile not being loaded (ksh) when opening shell in X
On Tue, Apr 27, 2021 at 08:04:32AM +0300, Pierre-Philipp Braun wrote: Could also just source your profile in your .xsession. That's what I'm in the habit of doing. I believe there's no need for neither login-shells nor those X-level tricks. To load the interactive environment into xterms or screen, I usually to define ENV accordingly in /etc/profile or .profile. Not sure it's the right way to also put PATH in (k)shrc, but it would also work. /etc/profile: export ENV=/etc/shrc or ~/.profile: export ENV=/root/.shrc That's very interesting. Can someone explain what this does?
Re: .profile not being loaded (ksh) when opening shell in X
On Mon, Apr 26, 2021 at 05:46:14PM -0400, Allan Streib wrote: "tetrahe...@danwin1210.me" writes: It looks like the custom $PATH is not being passed from the login shell on downwards, since ~/.profile is only read by a login shell. I just was looking into the same thing last night. The ksh shell in the xterm didn't seem to be processing my .profile. Adding the '-ls' argument to the xterm command resolved that. -ls This option indicates that the shell that is started in the xterm window will be a login shell (i.e., the first character of argv[0] will be a dash, indicating to the shell that it should read the user's .login or .profile). Thanks. Yes, that would work, but I feel like the contents of ~/.profile should be available to other commands as well, not just the xterm window.
Re: .profile not being loaded (ksh) when opening shell in X
On Tue, Apr 27, 2021 at 12:17:55PM +, tetrahe...@danwin1210.me wrote: > On Tue, Apr 27, 2021 at 08:04:32AM +0300, Pierre-Philipp Braun wrote: > > I believe there's no need for neither login-shells nor those X-level > > tricks. To load the interactive environment into xterms or screen, I > > usually to define ENV accordingly in /etc/profile or .profile. Not sure > > it's the right way to also put PATH in (k)shrc, but it would also work. > > > > /etc/profile: export ENV=/etc/shrc > > > > or > > > > ~/.profile: export ENV=/root/.shrc > > That's very interesting. Can someone explain what this does? This is incorrect (see upthread.) ENV is for setting what your interactive rc ought to be. You usually point it at ~/.kshrc. If your session hasn't loaded ~/.profile in order to load $ENV then the kshrc won't necessarily be loaded by your shell no matter what. For ~/.profile to be in your environmnt you definitely need to load it in your xsession. Danny
Re: Remote wipe software
On Tue, Apr 27, 2021 at 08:06:46AM -0400, Nick Holland wrote: > # dd if=/dev/random of=/dev/rsdXc bs=1m I don't know Oliver's specific case but it's worth noting that you probably want to check the output of mount rather than hardcoding a value; if you need remote wipes then you probably need full disk encryption and if I remember correctly your device number isn't always guaranteed there. Root is on sd3 for now, it might be on sd2 next boot, etc. I may be misinformed though.
Re: .profile not being loaded (ksh) when opening shell in X
On Tue, Apr 27, 2021 at 12:19:36PM +, tetrahe...@danwin1210.me wrote: > On Tue, Apr 27, 2021 at 09:37:05AM +0200, Alexandre Ratchov wrote: > > If you're using a display manager (xenodm or whatever), you've to > > include your .profile in your session login script (X equivalent of > > shell's ~/.profile concept), so the envoronment (and other global > > login settings) from your .profile become visible to all X programs, > > not only xterm. For instance put: > > > > . ~/.profile > > > > at the beginning of our ~/.xsession > > > > If you're using xinit(1), your ~/.profile is already loaded by > > the login shell. > > That seems the right way to go, if the other suggested solution of defining > ENV doesn't do the trick. > Note that ENV processing is only done for interactive shells. Traditionally, ENV would point the a ~/.kshrc file that contains init commands only relevant for interactive use. See the ksh man page for details. -Otto
Re: Remote wipe software
> Thanks for your response, a lot to think about sure. I suppose having > some sort of phone home daemon running to know whether or not to dd > itself is probably the best way to at least somewhat destroy itself in a > disaster scenario As a note, it seems that dd on an SSD is not so effective due to the wear balancing algorithm. Instead the "ATA Secure Erase" command should be used (of course you have to trust that the SSD vendor has implemented that correctly in the ROM / hardware).
Re: Remote wipe software
Thanks for your response, a lot to think about sure. I suppose having some sort of phone home daemon running to know whether or not to dd itself is probably the best way to at least somewhat destroy itself in a disaster scenario > Label them carefully and destroy them when done to prevent very > unhappy accidents later! Like Employee_Financial_Data.xlsx? -- Oliver Leaver-Smith TZ=Europe/London
Re: .profile not being loaded (ksh) when opening shell in X
On 2021-04-26, tetrahe...@danwin1210.me wrote: > I have some custom additions to my $PATH. They're defined in ~/.profile > and they are correctly loaded when I log in from a text console. > > When I log in to X (cwm) and open a terminal window, $PATH does not > contain the entries. > > I tried `chmod +x` on my .profile but that didn't help. > > Both the text console and the X terminal window are using ksh. > > When I call `/bin/ksh -l` then the resulting shell contains the correct > additions to $PATH. > > It looks like the custom $PATH is not being passed from the login shell > on downwards, since ~/.profile is only read by a login shell. Seems that your terminal in X is not configured to run a login shell. By default that is done for xterm via .Xdefaults in a new user's profile directory (copied from /etc/skel) but if you use a different terminal or have modified these files, that won't be used. > ~/.kshrc is (according to ksh(1)) read by every spawning shell, but I > don't see any documentation or examples on the Internet where someone > defined their $PATH in ~/.kshrc ... That is only if ENV is set. > What's the correct way to set $PATH and have it stick no matter where > and when the shell is spawned? If it's just PATH or some other environment variable, setting it for the relevant class in /etc/login.conf is one option. But probably simpler to configure your X terminal to run login shells.
Re: Remote wipe software
On 4/27/21 5:41 AM, Oliver Leaver-Smith wrote: Hello misc@ I wonder if anyone could recommend remote wipe software for OpenBSD, should someone want to start using it in an enterprise setting where such features are a requirement? Thanks in advance, Remote wiping an openbsd system...depends on your company policy, but there are options. I'm kinda assuming you are looking for an OpenBSD solution, any wiping system will wipe any supported drives on any machine. # dd if=/dev/random of=/dev/rsdXc bs=1m will clear drive sdX very nicely, and quite quickly compared to other OSs -- to the point I've often installed OpenBSD remotely, then done this to clear other OSs from systems. OpenBSD's performance from its random number generator is fantastic. IF your policy is a "multi-pass" wiping, I'd suggest doing a few passes with /dev/random, then following up with /dev/zero, so you can quickly and easily see if a particular drive has been cleared -- if it is all zeros, you know you have completed the required number of passes (it's easy to see zeros, a little harder to determine if data is "random" or "just not understood". If a one-pass wipe is sufficient by your company policy, a running OpenBSD system can wipe itself. Yes, you will get error messages when the dd is done, but...you don't really care, right? You can even do the dd thing from a bsd.rd kernel, network booted or physical media. Many years ago, I found that OpenBSD's full install had a faster /dev/random (by a large margin) than the bsd.rd /dev/random. I've got no idea if that's true now. When tasked with a number of machines to wipe, I've actually made wipe disks -- built a CD (or other) install media with the startup scripts set to wipe all drives in the system, unprompted. Boot the machine off the media, and let it run. Label them carefully and destroy them when done to prevent very unhappy accidents later! Nick.
Re: Remote wipe software
On Tue Apr 27, 2021 at 10:49 AM BST, Janne Johansson wrote: > Regardless of OS, the "easiest" setup is where you encrypt the drives > and wipe by "forgetting" the keys. Then you can dd the disks if it > makes someone else happy but having FDE and changing the key to > something random that you don't store, and then doing a normal wipe in > the simplest of terms would cover a lot of the practical attacks. > > For the ones concerned with theoretical and imaginary enemies, > PXE-booting into a DBAN.iso or similar wiping solutions is probably > the next step. Also OS-independent. Thanks Janne. Certainly those are two useful methods for ensuring that the disk is wipe or the contents are not accessible. The scenario I am thinking about is say a laptop is left in a suspended state, and forgotten on a train somewhere. The contents of the drive would be recoverable in that state unless something remote was to lock it down or wipe the disk -- Oliver Leaver-Smith TZ=Europe/London
Re: Remote wipe software
Den tis 27 apr. 2021 kl 11:44 skrev Oliver Leaver-Smith : > Hello misc@ > I wonder if anyone could recommend remote wipe software for OpenBSD, should > someone want to start using it in an enterprise setting where such features > are a requirement? > Thanks in advance, Regardless of OS, the "easiest" setup is where you encrypt the drives and wipe by "forgetting" the keys. Then you can dd the disks if it makes someone else happy but having FDE and changing the key to something random that you don't store, and then doing a normal wipe in the simplest of terms would cover a lot of the practical attacks. For the ones concerned with theoretical and imaginary enemies, PXE-booting into a DBAN.iso or similar wiping solutions is probably the next step. Also OS-independent. -- May the most significant bit of your life be positive.
Remote wipe software
Hello misc@ I wonder if anyone could recommend remote wipe software for OpenBSD, should someone want to start using it in an enterprise setting where such features are a requirement? Thanks in advance, ols -- Oliver Leaver-Smith TZ=Europe/London
Re: .profile not being loaded (ksh) when opening shell in X
On Mon, Apr 26, 2021 at 09:26:19PM +, tetrahe...@danwin1210.me wrote: > I have some custom additions to my $PATH. They're defined in ~/.profile and > they are correctly loaded when I log in from a text console. > > When I log in to X (cwm) and open a terminal window, $PATH does not contain > the entries. > > I tried `chmod +x` on my .profile but that didn't help. > > Both the text console and the X terminal window are using ksh. > > When I call `/bin/ksh -l` then the resulting shell contains the correct > additions to $PATH. > > It looks like the custom $PATH is not being passed from the login shell on > downwards, since ~/.profile is only read by a login shell. > > ~/.kshrc is (according to ksh(1)) read by every spawning shell, but I don't > see any documentation or examples on the Internet where someone defined > their $PATH in ~/.kshrc ... > > What's the correct way to set $PATH and have it stick no matter where and > when the shell is spawned? If you're using a display manager (xenodm or whatever), you've to include your .profile in your session login script (X equivalent of shell's ~/.profile concept), so the envoronment (and other global login settings) from your .profile become visible to all X programs, not only xterm. For instance put: . ~/.profile at the beginning of our ~/.xsession If you're using xinit(1), your ~/.profile is already loaded by the login shell.
