Re: Terminal emulators can't read .profile
* MERIGHI Marcus mcmer-open...@tor.at [2012-12-10 12:48:26 +0100]: f...@zhou.es (Feng Zhou), 2012.12.10 (Mon) 12:02 (CET): I was trying out st and urxvt as a replacement for xterm, and it turned out that all the settings I put in ~/.profile are not recognised when I use either st or urxvt. Is this a bug or an expected behaviour that I need to do something about to use other terminals? The shell was not changed, it was the default ksh. At first I thought it was a problem of st, but it happened to urxvt too. So I thought it's best to ask here. Any help is much appreciated. I am guessing here, but from the times I used rxvt there's still: Rxvt*loginShell: TRUE in my .Xdefaults. Bye, Marcus I use urxvt with cwm. You need to to use the ~/.Xdefaults file as others have suggested: URxvt.loginShell:true ... This will solve your problem. BTW, it's documented on the FAQ I believe. Jamie
Re: OSPF + BGP routing loop
On 2012-12-12, Loïc Blot loic.b...@unix-experience.fr wrote: Hello to OpenBSD Community. I am testing OSPF + BGP dynamic routing. I'm happy to see OSPF learn BGP learnt routes natively. I have a problem with my default route. As you see Pala1 (one of the two main router) learn default route from 14.14.14.1 (which is my simulated backbone router). OSPF must redistribute also default route to GWPala1 (and GWPala2) which are the client gateways. Accordingly, OSPF also redistribute the default route between Pala1 and Pala2 (the second main router), and there is a routing loop. In fact OSPF is prior than BGP and i want default BGP route be prior than OSPF. How can i proceed to break this priority for the default route only ? At this moment i have thought: - Block OSPF packets from the other router Then OSPF won't work... - Recompile the kernel to make BGP prior than OSPF This wouldn't be the kernel - daemons add routes with priority RTP_BGP / RTP_OSPF - this would be a wrong approach too. Say you have an IXP-facing /24 which is advertised from external sources over BGP and internally over OSPF, you wouldn't want to prefer the external route.. Is there any option to block route from some peers on OSPF ? Have you got another idea ? ospfd doesn't allow you to filter the routes imported to the kernel, In a similar scenario I ran bgpd on the internal gateways and fed a default route to them that way instead, then use OSPF for loopbacks, peer links (/30's / IXP subnets) and internal subnets (i.e. all external internet routes are carried in BGP). Another way to handle this would be to have a carp address on the inside of the main routers and on the client gateways, point a static default route to that carp address, you can again still use ospf for announcing networks behind the gateway.
Re: gnome startup error
On 2012-12-13, Girish Venkatachalam girishvenkatacha...@gmail.com wrote: Has anyone got this error when starting gnome? The enumeration fails and gnome fails to start. The /tmp,/var, /root directories are mounted on mfs. -Girish /usr/local/bin/gnome-keyring-daemon:/usr/local/lib/libgcr-base-3.so.0.0: /usr/local/bin/gnome-keyring-daemon : WARNING: symbol(pkix_asn1_tab) size mismatch, relink your program (I manually quoted the above as it was after the -- signature boundary) This looks like incorrectly built software.. Did you build yourself or is it from packages? Did you remove old versions of libraries before building? Did you update all packages together?
Re: gnome startup error
On Thu, Dec 13, 2012 at 11:04:45AM +, Stuart Henderson wrote: On 2012-12-13, Girish Venkatachalam girishvenkatacha...@gmail.com wrote: Has anyone got this error when starting gnome? The enumeration fails and gnome fails to start. The /tmp,/var, /root directories are mounted on mfs. -Girish /usr/local/bin/gnome-keyring-daemon:/usr/local/lib/libgcr-base-3.so.0.0: /usr/local/bin/gnome-keyring-daemon : WARNING: symbol(pkix_asn1_tab) size mismatch, relink your program (I manually quoted the above as it was after the -- signature boundary) This looks like incorrectly built software.. Did you build yourself or is it from packages? Did you remove old versions of libraries before building? Did you update all packages together? It's just a warning which has no incidence. It's fixed in current with the newer libtool. But the OP didn't give any information about his setup, whether he followed the docs, ... os it is impossible to help him. This smells like a dbus no running issue, but without info, it's impossible to say... -- Antoine
Re: Terminal emulators can't read .profile
I confirm that putting URxvt.loginShell:true into ~/.Xdefaults works for urxvt. Sorry I didn't get to reply earlier. I searched the FAQ after you mentioned it and it indeed is documented in section 8.16. But I didn't think of it and didn't know enough to know what keywords to search in the beginning. However, st doesn't seem to be able to read .profile with st.loginShell:true. If anyone knows why, it'd be great if you let me know. I know nothing about xorg. Nonetheless, I'm happy to have gotten urxvt working. Thank you very much all for your help. Feng On 13/12/2012, at 8:52 PM, Jamie Paul Griffin ja...@kode5.net wrote: * MERIGHI Marcus mcmer-open...@tor.at [2012-12-10 12:48:26 +0100]: f...@zhou.es (Feng Zhou), 2012.12.10 (Mon) 12:02 (CET): I was trying out st and urxvt as a replacement for xterm, and it turned out that all the settings I put in ~/.profile are not recognised when I use either st or urxvt. Is this a bug or an expected behaviour that I need to do something about to use other terminals? The shell was not changed, it was the default ksh. At first I thought it was a problem of st, but it happened to urxvt too. So I thought it's best to ask here. Any help is much appreciated. I am guessing here, but from the times I used rxvt there's still: Rxvt*loginShell: TRUE in my .Xdefaults. Bye, Marcus I use urxvt with cwm. You need to to use the ~/.Xdefaults file as others have suggested: URxvt.loginShell:true ... This will solve your problem. BTW, it's documented on the FAQ I believe. Jamie
Re: Terminal emulators can't read .profile
On 12/13/2012 01:14 PM, Feng Zhou wrote: However, st doesn't seem to be able to read .profile [...] Just to be a bit more precise here: It's *not* the terminal emulator that reads '.profile'. The terminal emulator just invokes a shell and the shell parses its configuration files. Regarding '.profile', I'll quote the ksh man page (assuming you are using ksh as your shell): -l Login shell. If the basename the shell is called with (i.e. argv[0]) starts with `-' or if this option is used, the shell is assumed to be a login shell and the shell reads and executes the contents of /etc/profile and $HOME/.profile if they exist and are readable. So it all comes down to *how* (i.e. with what options) the shell gets invoked. Don't confuse the terminal emulator with the shell, as these are two distinct things.
Re: Terminal emulators can't read .profile
Yep, I understand the difference between terminal emulator and shell. Thanks for the clarification anyway. It was just easier to type than with st*loginShell:true set in .Xdefault, st doesn't seem to be able to launch urxvt as login shell that reads .profile at start-up. On 13/12/2012, at 11:59 PM, Dustin Fechner d...@hush.com wrote: On 12/13/2012 01:14 PM, Feng Zhou wrote: However, st doesn't seem to be able to read .profile [...] Just to be a bit more precise here: It's *not* the terminal emulator that reads '.profile'. The terminal emulator just invokes a shell and the shell parses its configuration files. Regarding '.profile', I'll quote the ksh man page (assuming you are using ksh as your shell): -l Login shell. If the basename the shell is called with (i.e. argv[0]) starts with `-' or if this option is used, the shell is assumed to be a login shell and the shell reads and executes the contents of /etc/profile and $HOME/.profile if they exist and are readable. So it all comes down to *how* (i.e. with what options) the shell gets invoked. Don't confuse the terminal emulator with the shell, as these are two distinct things.
login_radius support for encrypted authentication type?
Hi! I have an OpenBSD 5.2 installation on a Soekris net4801 used as a router, DNS server and a SSH tunnel proxy. I have configured the login_radius service in my login.conf and all works reasonably well but from what I can tell login_radius only supports the clear-text PAP authentication type. So my question is am I missing something and it's possible to use CHAP or any other encrypted auth types with login_radius or is unencrypted PAP the only supported auth type? I would normaly not make a fuss about it but OpenBSD being as security centric as it is I find it a bit awkward it would support only a plain-text method in such an important auth mechanism. Best regards, Aleš Golob Sistemska podpora Gora Informacijske rešitve d.o.o., Ljubljana Dunajska 21 Tel: +386 1 23 44 856 SI-1000 Ljubljana Fax: +386 1 23 44 870 Slovenija http://www.gora.si E-mail:ales.go...@gora.si
Re: login_radius support for encrypted authentication type?
I haven't worked with OpenBSD in this context, but I've setup 802.1X auth for layer-2 wireless. It's LDAP backed. We happen to also run a samba3 domain, so LDAP also stores NTLM hashes. I'm not a radius expert, but the only mechanism that seems to be able to deal with non clear passwords seem to have to deal with NTLM hashes. If there isn't a way to pass the auth request through some kind of layer that will give you a pass/fail response, I'm pretty sure you're stuck with having to store your radius passwords in the clear. -Stephen
suspected typo in /usr/X11R6/README on macppc (5.2-RELEASE)
the line: xmodmap -e keysym Mode_switch = Mode_switch Pointer_EnableKeys shound instead be: xmodmap -e keysym Mode_switch = Pointer_EnableKeys
[OpenBSD 5.2] Bug in fileutils from ports/misc
Hi all from /usr/ports/misc/fileutils, we cannot make install This ends with an source-code like error even from a NEW 'so a perfectly clear' setup. I tried on other computers so it is not a local problem... I tried to download fileutils sources from elsewhere but error is simply the same. has anyone successfully compiled this port ? (I did many times with older OpenBSD's) I was looking for gls that is inside this port. Thanks gmake[3]: Entering directory `/usr/ports/pobj/fileutils-4.1/build-i386/src' source='/usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/dircolors.c' object='dircolors.o' libtool=no \ depfile='.deps/dircolors.Po' tmpdepfile='.deps/dircolors.TPo' \ depmode=gcc3 /bin/sh /usr/ports/pobj/fileutils-4.1/fileutils-4.1/depcomp \ cc -DLOCALEDIR=\/usr/local/share/locale\ -DSHAREDIR=\/usr/local/share\ -DHAVE_CONFIG_H -I.. -I/usr/ports/pobj/fileutils-4.1/fileutils-4.1/src -I/usr/ports/pobj/fileutils-4.1/fileutils-4.1/lib -I/usr/local/include -O2 -pipe -I/usr/local/include -c -o dircolors.o `test -f /usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/dircolors.c || echo '/usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/'`/usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/dircolors.c In file included from /usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/dircolors.c:31: /usr/ports/pobj/fileutils-4.1/fileutils-4.1/lib/getline.h:32: error: conflicting types for 'getline' /usr/include/stdio.h:244: error: previous declaration of 'getline' was here /usr/ports/pobj/fileutils-4.1/fileutils-4.1/lib/getline.h:35: error: conflicting types for 'getdelim' /usr/include/stdio.h:242: error: previous declaration of 'getdelim' was here gmake[3]: *** [dircolors.o] Error 1 gmake[3]: Leaving directory `/usr/ports/pobj/fileutils-4.1/build-i386/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/pobj/fileutils-4.1/build-i386/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/pobj/fileutils-4.1/build-i386' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/misc/fileutils (line 2496 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/misc/fileutils (line 2245 of /usr/ports/infrastructure/mk/bsd.port.mk). Cordialement Francois Pussault 3701 - 8 rue Marcel Pagnol 31100 Toulouse France +33 6 17 230 820 +33 5 34 365 269 fpussa...@contactoffice.fr
Re: [OpenBSD 5.2] Bug in fileutils from ports/misc
On Thu, Dec 13, 2012 at 09:01:16PM +0100, Francois Pussault wrote: Hi all from /usr/ports/misc/fileutils, we cannot make install This ends with an source-code like error even from a NEW 'so a perfectly clear' setup. I tried on other computers so it is not a local problem... I tried to download fileutils sources from elsewhere but error is simply the same. has anyone successfully compiled this port ? (I did many times with older OpenBSD's) I was looking for gls that is inside this port. Thanks misc/Makefile: Revision 1.148: Tue Mar 20 16:36:16 2012 UTC (8 months, 3 weeks ago) by naddy fileutils, sh-utils, textutils are superseded by coreutils. gmake[3]: Entering directory `/usr/ports/pobj/fileutils-4.1/build-i386/src' source='/usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/dircolors.c' object='dircolors.o' libtool=no \ depfile='.deps/dircolors.Po' tmpdepfile='.deps/dircolors.TPo' \ depmode=gcc3 /bin/sh /usr/ports/pobj/fileutils-4.1/fileutils-4.1/depcomp \ cc -DLOCALEDIR=\/usr/local/share/locale\ -DSHAREDIR=\/usr/local/share\ -DHAVE_CONFIG_H -I.. -I/usr/ports/pobj/fileutils-4.1/fileutils-4.1/src -I/usr/ports/pobj/fileutils-4.1/fileutils-4.1/lib -I/usr/local/include -O2 -pipe -I/usr/local/include -c -o dircolors.o `test -f /usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/dircolors.c || echo '/usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/'`/usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/dircolors.c In file included from /usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/dircolors.c:31: /usr/ports/pobj/fileutils-4.1/fileutils-4.1/lib/getline.h:32: error: conflicting types for 'getline' /usr/include/stdio.h:244: error: previous declaration of 'getline' was here /usr/ports/pobj/fileutils-4.1/fileutils-4.1/lib/getline.h:35: error: conflicting types for 'getdelim' /usr/include/stdio.h:242: error: previous declaration of 'getdelim' was here gmake[3]: *** [dircolors.o] Error 1 gmake[3]: Leaving directory `/usr/ports/pobj/fileutils-4.1/build-i386/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/pobj/fileutils-4.1/build-i386/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/pobj/fileutils-4.1/build-i386' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/misc/fileutils (line 2496 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/misc/fileutils (line 2245 of /usr/ports/infrastructure/mk/bsd.port.mk). Cordialement Francois Pussault 3701 - 8 rue Marcel Pagnol 31100 Toulouse France +33 6 17 230 820 +33 5 34 365 269 fpussa...@contactoffice.fr -- Antoine
Re: [OpenBSD 5.2] Bug in fileutils from ports/misc
Thanks I missed that :) From: Antoine Jacoutot ajacou...@bsdfrog.org Sent: Thu Dec 13 21:05:41 CET 2012 To: Francois Pussault fpussa...@contactoffice.fr Subject: Re: [OpenBSD 5.2] Bug in fileutils from ports/misc On Thu, Dec 13, 2012 at 09:01:16PM +0100, Francois Pussault wrote: Hi all from /usr/ports/misc/fileutils, we cannot make install This ends with an source-code like error even from a NEW 'so a perfectly clear' setup. I tried on other computers so it is not a local problem... I tried to download fileutils sources from elsewhere but error is simply the same. has anyone successfully compiled this port ? (I did many times with older OpenBSD's) I was looking for gls that is inside this port. Thanks misc/Makefile: Revision 1.148: Tue Mar 20 16:36:16 2012 UTC (8 months, 3 weeks ago) by naddy fileutils, sh-utils, textutils are superseded by coreutils. gmake[3]: Entering directory `/usr/ports/pobj/fileutils-4.1/build-i386/src' source='/usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/dircolors.c' object='dircolors.o' libtool=no \ depfile='.deps/dircolors.Po' tmpdepfile='.deps/dircolors.TPo' \ depmode=gcc3 /bin/sh /usr/ports/pobj/fileutils-4.1/fileutils-4.1/depcomp \ cc -DLOCALEDIR=\/usr/local/share/locale\ -DSHAREDIR=\/usr/local/share\ -DHAVE_CONFIG_H -I.. -I/usr/ports/pobj/fileutils-4.1/fileutils-4.1/src -I/usr/ports/pobj/fileutils-4.1/fileutils-4.1/lib -I/usr/local/include -O2 -pipe -I/usr/local/include -c -o dircolors.o `test -f /usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/dircolors.c || echo '/usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/'`/usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/dircolors.c In file included from /usr/ports/pobj/fileutils-4.1/fileutils-4.1/src/dircolors.c:31: /usr/ports/pobj/fileutils-4.1/fileutils-4.1/lib/getline.h:32: error: conflicting types for 'getline' /usr/include/stdio.h:244: error: previous declaration of 'getline' was here /usr/ports/pobj/fileutils-4.1/fileutils-4.1/lib/getline.h:35: error: conflicting types for 'getdelim' /usr/include/stdio.h:242: error: previous declaration of 'getdelim' was here gmake[3]: *** [dircolors.o] Error 1 gmake[3]: Leaving directory `/usr/ports/pobj/fileutils-4.1/build-i386/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/pobj/fileutils-4.1/build-i386/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/pobj/fileutils-4.1/build-i386' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/misc/fileutils (line 2496 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/misc/fileutils (line 2245 of /usr/ports/infrastructure/mk/bsd.port.mk). Cordialement Francois Pussault 3701 - 8 rue Marcel Pagnol 31100 Toulouse France +33 6 17 230 820 +33 5 34 365 269 fpussa...@contactoffice.fr -- Antoine Cordialement Francois Pussault 3701 - 8 rue Marcel Pagnol 31100 Toulouse France +33 6 17 230 820 +33 5 34 365 269 fpussa...@contactoffice.fr
Re: [OpenBSD 5.2] Bug in fileutils from ports/misc
Francois Pussault fpussa...@contactoffice.fr wrote: from /usr/ports/misc/fileutils, we cannot make install This port doesn't exist any longer in 5.2. Well, it does, because I forgot to delete it, but it had already been unhooked from the bulk builds. It has been superseded by sysutils/coreutils. I was looking for gls that is inside this port. If all you are looking for is colorized output, I would recommend sysutils/colorls instead. -- Christian naddy Weisgerber na...@mips.inka.de
Re: [OpenBSD 5.2] Bug in fileutils from ports/misc
Thanks I did so From: Christian Weisgerber na...@mips.inka.de Sent: Thu Dec 13 21:56:21 CET 2012 To: misc@openbsd.org Subject: Re: [OpenBSD 5.2] Bug in fileutils from ports/misc Francois Pussault fpussa...@contactoffice.fr wrote: from /usr/ports/misc/fileutils, we cannot make install This port doesn't exist any longer in 5.2. Well, it does, because I forgot to delete it, but it had already been unhooked from the bulk builds. It has been superseded by sysutils/coreutils. I was looking for gls that is inside this port. If all you are looking for is colorized output, I would recommend sysutils/colorls instead. -- Christian naddy Weisgerber na...@mips.inka.de Cordialement Francois Pussault 3701 - 8 rue Marcel Pagnol 31100 Toulouse France +33 6 17 230 820 +33 5 34 365 269 fpussa...@contactoffice.fr
Re: for students or your children
On Wed, Dec 12, 2012 at 11:03:50AM +0530, Jay Patel wrote: Hi all .. is OpenBSD taking part in google code-in : The answer is No, as far as I'm aware. Did you have a specific project in mind? You can get fame and glory without participating in Google-sponsored events :) http://www.google-melange.com/gci/homepage/google/gci2012 Thanks, Jay.
