trouble autobooting loongson on gdium?
So, cool, I have OpenBSD 4.7 installed and booted on my Gdium laptop. Now, here are the small problem I faced and am facing. Wireless network didn't work during setup. I used wireless. The device was recognized. ifconfig let me fiddle with it. It gets a DHCP address, but that's it. Maybe my local network. I have OpenBSD/macppc working wireless, but maybe I forgot how. Anyway, ok, move on. The instructions are a bit lacking if you have a completely empty USB key. The installer doesn't seem to handle this well. It seemed to create an ext2 partition, but it was too small I think. I couldn't figure out how to create the ext2 partition and file system in OpenBSD. So what I did is I partitioned the key under Linux. I made a 100MB ext2 partition and the rest OpenBSD. I put bsd, boot, and bsd.rd all on the ext2 partition. From here: http://ftp5.usa.openbsd.org/pub/OpenBSD/4.7/loongson/ I booted bsd.rd with pmon. This part of the instructions worked well. I had tried the miniroot.fs approach. It didn't work, but I'm just slightly out of realm here and probably messed up. Now, the real problems. At the end of setup, I get an error: mkdir /mnt2/boot failed Won't be able to boot from sd1. /mnt2/boot is a file. And then these instructions: ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/loongson/INSTALL.loongson Gdium systems final steps: Gdium systems do not have a boot menu, and directly boot the system (Linux, by default). Unfortunately, the OpenBSD bootloader operation is very limited on this machine, as it can not access USB devices (which means no keyboard input as well). To overcome this and be able to boot OpenBSD nevertheless, the bootloader relies upon PMON's ability to load a Linux so-called ``initrd'' image. By making PMON load the kernel as the ``initrd''i image, and then run the bootloader, the bootloader will be able to ``load'' the OpenBSD kernel correctly. The path to the file booted by default is set in the `al' environment variable, and the path to the initrd image is set in the `rd' environment variable. To boot the bsd kernel on the G-Key by default, assuming it has been copied to /boot/bsd on the first ext3 partition, and the bootloader has been copied to /boot/boot on the same filesystem, the settings are: PMON set al /dev/fs/e...@usbg0/boot/boot PMON set rd /dev/fs/e...@usbg0/boot/bsd are a bit confusing and unclear to me. After I set the variables, then what? Power cycle and it should autoboot? That didn't work for me at first. What worked I think: load /dev/fs/e...@usb0/bsd g Ok, I rebooted, and it autobooted, then I am prompted for root device, I type sd1, and swap device (I have no swap). Hm, there is no /boot, even though there was /mnt2/boot. So let's try cp /usr/mdec/boot / Nope, didn't help. Well, as long as I don't reboot, it is looking good. I'll try to fiddle around more with booting. There's apparently no installboot here. Thanks, - Jay
Re: trouble autobooting loongson on gdium?
wireless Does it work after the installation? The installation media is supposed I don't think so. The device is recognized. ifconfig reports stuff. I think I even got a DHCP address, but can't ping anything. I haven't setup wireless with OpenBSD in a while, so I might be doing something wrong. I do have it working on a macppc machine currently and used to have it on a sparc64 (switched to wired). This is vecause you copied boot, bsd and bsd.rd to the root of the Aha. And boot varies, per configuration? The one I put there might not be correct? Thank you. I'll try again. load code from an ext2fs partition, so the boot code can simply be copied there instead of needing a special tool to put it on a magic area Is the boot code a constant file, or does it vary per install/config? That is..the one I put there, isn't already correct? Anyway, thank you, I'll try again with an empty ext2 partition, and see what the installer does. I should have copied the install files somewhere, downloading them repeatedly now (twice already, I can wait, but I'm wasting bandwidth). - Jay Date: Sat, 24 Jul 2010 17:07:26 + From: m...@online.fr To: jay.kr...@cornell.edu CC: misc@openbsd.org Subject: Re: trouble autobooting loongson on gdium? Wireless network didn't work during setup. I used wireless. The device was recognized. ifconfig let me fiddle with it. It gets a DHCP address, but that's it. Maybe my local network. I have OpenBSD/macppc working wireless, but maybe I forgot how. Anyway, ok, move on. Does it work after the installation? The installation media is supposed to have all the required firmware files, but one might have been forgotten. The instructions are a bit lacking if you have a completely empty USB key. The installer doesn't seem to handle this well. It seemed to create an ext2 partition, but it was too small I think. You are right. This has been fixed post release. I couldn't figure out how to create the ext2 partition and file system in OpenBSD. The installer uses ``newfs -t ext2fs -O 1 -b 4096'' on gdium (the O and b options are used to circumvent shortcomings in the PMON ext2fs code). At the end of setup, I get an error: mkdir /mnt2/boot failed Won't be able to boot from sd1. /mnt2/boot is a file. This is vecause you copied boot, bsd and bsd.rd to the root of the ext2fs partition. The installer (and the documentation) expect these files to be in the boot/ subdirectory. PMON set al /dev/fs/e...@usbg0/boot/boot PMON set rd /dev/fs/e...@usbg0/boot/bsd are a bit confusing and unclear to me. After I set the variables, then what? If you have the files in the root of the ext2fs partition, you will need to adjust the path first: PMON set al /dev/fs/e...@usbg0/boot PMON set rd /dev/fs/e...@usbg0/bsd Power cycle and it should autoboot? Yes. What worked I think: load /dev/fs/e...@usb0/bsd g This will boot a kernel, but it will ask for its root device everytime (which is why the boot loader is preferred over direct boot from PMON). There's apparently no installboot here. No, there isn't. The bastardized PMON shipped on these machines can only load code from an ext2fs partition, so the boot code can simply be copied there instead of needing a special tool to put it on a magic area on the disk. Miod
Re: trouble autobooting loongson on gdium?
I updated the pmon paths. It autoboots. It autoboots the kernel. But then it prompts me for two devices (swap and I guess root fs). How do I remove those prompts? same: $ dmesg | grep ral ral0 at pci0 dev 13 function 0 Ralink RT2561S rev 0x00: irq 6, address 00:0e:8e:1e:ef:d0 ral0: MAC/BBP RT2561C, RF RT2527 Thanks, - Jay Date: Sun, 25 Jul 2010 17:54:41 + From: m...@online.fr To: jay.kr...@cornell.edu CC: misc@openbsd.org Subject: Re: trouble autobooting loongson on gdium? Does it work after the installation? The installation media is supposed I don't think so. The device is recognized. ifconfig reports stuff. I think I even got a DHCP address, but can't ping anything. Hmm... did the particular wireless chip change on recent models? On the gdium here it attaches as: ral0 at pci0 dev 13 function 0 Ralink RT2561S rev 0x00: irq 6, address 00:0e:8e:1f:03:3a ral0: MAC/BBP RT2561C, RF RT2527 ...and I can connect to the neighbour's access point with a simple ``dhclient ral0''. This is vecause you copied boot, bsd and bsd.rd to the root of the Aha. And boot varies, per configuration? The one I put there might not be correct? No, `boot' is the same for all supported loongson systems. But if you copy it to the root of the ext2fs partition, you can't create a directory of the same name. I.e. your partition contains /boot /bsd while the installer and the documentation expect /boot/ /boot/boot /boot/bsd but your layout is fine as long as you update the PMON paths to not have the `boot/' subdirectory in them. Miod
-static -lX11 breaks pthreads (4.6)
I haven't tried 4.7 yet.
OpenBSD xobsd.jkhome 4.6 obj#0 i386
$ cat 1.c
#include stdio.h
#include pthread.h
void* thread1(void* a)
{
printf(%p\n, pthread_self());
return 0;
}
int main()
{
pthread_t t1;
printf(%p\n, pthread_self());
pthread_create(t1, NULL, thread1, 0);
sleep(100);
return 0;
}
$ gcc 1.c -L/usr/X11R6/lib -lX11 -pthread -static
$ ./a.out
0x0
0x0
I use -static deliberately so I can give binaries that work on other OpenBSD
versions.
I give source too, it's not too keep source private, but it is for ease of
use.
Putting -lpthread (not -pthread) ahead of -lX11 fixes it.
I suppose there is a goal to enable using -lX11 without using -pthread?
And I suppose -static isn't meant to be much supported?
Merging libpthread into libc is the way imho.
- Jay
Re: trouble autobooting loongson on gdium?
Oh, yeah, good guess. :) I do have OpenBSD on a separate USB flash drive, not in the G position. - Jay Date: Mon, 26 Jul 2010 13:30:59 + From: m...@online.fr To: jay.kr...@cornell.edu CC: misc@openbsd.org Subject: Re: trouble autobooting loongson on gdium? I updated the pmon paths. It autoboots. It autoboots the kernel. But then it prompts me for two devices (swap and I guess root fs). How do I remove those prompts? The kernel on Gdium expects its boot device to be the USB device found in the G-Key slot (usbg0 in PMON). Are you still trying to boot from an USB key not inserted in the g-key slot?
get/set/make/swapcontext please?
Hey. I'm sure you've heard this before, but here's another vote: Please provide get/set/make/swapcontext. (and/or kernel threads.) They are Posix-standard, but, admittedly, deprecated. And, admittedly, most applications can use pthreads instead. Longer story: Modula-3. Provides threads in its runtime. Kind of like Java. (though we produce native, optionally safe, etc.) We have 5 or so (!) options for providing them. Win32 threads pthreads That covers just about all platforms. Now, for some reason, and I still need to debug/understand this, OpenBSD pthreads don't work for us. We do need to be able to suspend/resume threads and get their context while suspended. We have two ways of doing this for pthreads platforms: send a signal and wait in the signal handler some use of semaphore here I think this semaphore thing runs afoul of typical usermode threading libraries, such as OpenBSD's. And apparently others e.g. FreeBSD and Darwin/MacOSX. On FreeBSD and Darwin we have custom code for suspend/resume. I think in some places it is based on the boehm gc. (In future we might do something like cooperative suspend. Which should be extremely portable.) Now, for systems without viable pthreads, we have another option. We can use get/set/make/swapcontext. This is fairly simple, portable, and works fairly well. Albeit won't take advantage of multiprocessor systems. But yet, some systems e.g.OpenBSD, don't have get/set/make/swapcontext. Not to fear, we have another approach, using sigaltstack. I thought I had this working on OpenBSD/x86, but I see hangs now. I should look into it further. So, the last option, desparate measure, requires per machine porting, is hacking on the jmpbuf. I have this working on x86, mips64 (loongson), powerpc, and maybe sparc64. But I'd rather not resort to this. (see http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/unix/C ommon/context/setjmp) Thanks, - Jay
Re: -static -lX11 breaks pthreads (4.6)
Merging libpthread into libc is the way imho. That would make it somewhat difficult to work on a second pthreads library... Like a second C library.. You kind of want there to be only one, but if you must have more, it is possible. The benefit of having only one is a smaller system and better interopability: Only one definition of FILE*, pthread_t, etc., all implemented by only one shared library each. The downside of having only one is you can't change the semantics without breaking things. And the current semantics where there are no kernel threads (right?), probably not ideal or desired for long. - Jay Date: Mon, 26 Jul 2010 10:30:52 -0400 Subject: Re: -static -lX11 breaks pthreads (4.6) From: ted.unangst@ To: jay.krell@ CC: misc@ ...
kill/sigsuspend vs. cc -pthread?
Following 163 lines are reduced from a very portable way to implement
threads in usermode,
without hacking jmpbuf, using sigaltstack to set the stack pointer.
On OpenBSD 4.6 x86 and powerpc it hangs if I use -pthread, but otherwise does
not.
The hang is in the while(..) sigsuspend(), not too surprising.
Using pthread_sigmask and pthread_kill(pthread_self()) doesn't fix it.
Any ideas?
Maybe it is fixed in 4.7? I'll try that soon.
The approach is described here:
http://www.usenix.org/event/usenix2000/general/full_papers/engelschall/engels
chall_html/index.html
and this is faithful rendition of it, except for reducing it a little here
I use -pthread to get at pthread_fork, and would rather not be fragile that
way -- works without -pthread, doesn't with.
If I have no other choice, I'll probably do without pthread_fork and
therefore without -pthread and with the fragility.
If I can get this to work I can stop hacking jmpbuf.
The code seems ok on MacOSX and Linux.
Thanks,
- Jay
#include assert.h
#include errno.h
#include setjmp.h
#include stdio.h
#include stdlib.h
#include string.h
#include stddef.h
#include unistd.h
#include signal.h
#include sys/mman.h
#include sys/signal.h
#define ZERO_MEMORY(a) (memset((a), 0, sizeof(a)))
typedef struct {
sigjmp_buf jb;
} Context;
#define SWAP_CONTEXT(oldc, newc) \
do { \
if (sigsetjmp((oldc)-jb, 1) == 0) \
siglongjmp((newc)-jb, 1); \
} while (0)
Context mctx_caller;
sig_atomic_t volatile mctx_called;
Context * volatile mctx_create;
void (* volatile mctx_create_func)(void);
sigset_t mctx_create_sigs;
void mctx_create_boot(void)
{
void (*volatile mctx_start_func)(void);
fprintf(stderr, mctx_create_boot\n);
sigprocmask(SIG_SETMASK, mctx_create_sigs, NULL);
mctx_start_func = mctx_create_func;
SWAP_CONTEXT(mctx_create, mctx_caller);
mctx_start_func();
abort(); /* not reached */
}
void mctx_create_trampoline(int sig)
{
fprintf(stderr, mctx_create_trampoline\n);
if (sigsetjmp(mctx_create-jb, 0) == 0)
{
mctx_called = 1;
return;
}
mctx_create_boot();
}
void
xMakeContext(
Context *context,
void (*function)(void),
void *stack,
size_t stack_size)
{
struct sigaction sa;
struct sigaction osa;
stack_t ss;
stack_t oss;
sigset_t osigs;
sigset_t sigs;
fprintf(stderr, xMakeContext\n);
ZERO_MEMORY(sa);
ZERO_MEMORY(osa);
ZERO_MEMORY(ss);
ZERO_MEMORY(oss);
ZERO_MEMORY(osigs);
ZERO_MEMORY(sigs);
sigemptyset(sigs);
sigaddset(sigs, SIGUSR1);
sigprocmask(SIG_BLOCK, sigs, osigs);
sa.sa_handler = mctx_create_trampoline;
sa.sa_flags = SA_ONSTACK;
sigemptyset(sa.sa_mask);
sigaction(SIGUSR1, sa, osa);
ss.ss_sp = stack;
ss.ss_size = stack_size;
ss.ss_flags = 0;
sigaltstack(ss, oss);
mctx_create = context;
mctx_create_func = function;
mctx_create_sigs = osigs;
mctx_called = 0;
kill(getpid(), SIGUSR1);
sigfillset(sigs);
sigdelset(sigs, SIGUSR1);
while (!mctx_called)
sigsuspend(sigs);
sigaltstack(NULL, ss);
ss.ss_flags = SS_DISABLE;
sigaltstack(ss, NULL);
if (!(oss.ss_flags SS_DISABLE))
sigaltstack(oss, NULL);
sigaction(SIGUSR1, osa, NULL);
sigprocmask(SIG_SETMASK, osigs, NULL);
SWAP_CONTEXT(mctx_caller, context);
}
void *
MakeContext (void (*p)(void), size_t words)
{
Context *c = (Context *)calloc (1, sizeof(*c));
size_t size = sizeof(void *) * words;
size_t pagesize = getpagesize();
char *sp = { 0 };
size_t pages = { 0 };
int er = { 0 };
if (c == NULL)
goto Error;
if (size = 0) return c;
if (size MINSIGSTKSZ) size = MINSIGSTKSZ;
/* Round up to a whole number of pages, and
* allocate two extra pages, one at the start
* and one at the end, and don't allow accessing
* either one (catch stack overflow and underflow).
*/
pages = (size + pagesize - 1) / pagesize + 2;
size = pages * pagesize;
sp = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_ANON | MAP_PRIVATE, -1,
0);
if (sp == NULL)
goto Error;
if (mprotect(sp, pagesize, PROT_NONE)) abort();
if (mprotect(sp + size - pagesize, pagesize, PROT_NONE)) abort();
xMakeContext(c, p, sp + pagesize, size - 2 * pagesize);
return c;
Error:
er = errno;
if (c) free(c);
if (sp) munmap(sp, size);
errno = er;
return NULL;
}
void F1(void)
{
fprintf(stderr, F1\n);
}
int main()
{
MakeContext(F1, 1000);
return 0;
}
Re: kill/sigsuspend vs. cc -pthread?
Thanks David, done. - Jay Date: Tue, 27 Jul 2010 09:28:10 +0200 Subject: Re: kill/sigsuspend vs. cc -pthread? From: dco...@gmail.com To: jay.kr...@cornell.edu CC: misc@openbsd.org On Tue, Jul 27, 2010 at 9:21 AM, Jay K wrote: Following 163 lines are reduced from a very portable way to implement threads in usermode, without hacking jmpbuf, using sigaltstack to set the stack pointer. On OpenBSD 4.6 x86 and powerpc it hangs if I use -pthread, but otherwise does not. The hang is in the while(..) sigsuspend(), not too surprising. Using pthread_sigmask and pthread_kill(pthread_self()) doesn't fix it. Any ideas? Maybe it is fixed in 4.7? I'll try that soon. This is really stuff for t...@. You're on the wrong mailing list. ciao, David
Java for other than x86/amd64?
We use Hudson to manage builds. It uses Java. It looks like there's nothing viable here for OpenBSD other than x86 and AMD64? I already have OpenBSD/x86 working. I have Linux/ppc, maybe Linux/sparc working. There's a zero assembly project that has eased things, but the web page says it is gcc and Linux specific. I don't yet know why. Kaffe doesn't work. I tried. Anyone working on this? I might poke around a little but I doubt I have sufficient time. Performance doesn't matter here, so even Linux emulation would suffice. e.g. on ppc and sparc64. That doesn't seem to be present, and I realize it not a small thing. Thanks, - Jay
Re: get/set/make/swapcontext please?
Right, thanks, I forgot to check boehm-gc. I believe others have learned/borrowed from it. Will do that next week. I am running successfully on mips64 (gdium). Had to come up with new (to me) trick for makecontext related to register T9/$25. Jay/phone To: jay.kr...@cornell.edu From: s...@spacehopper.org CC: misc@openbsd.org Subject: Re: get/set/make/swapcontext please? Date: Sat, 31 Jul 2010 14:56:59 +0100 On 2010-07-26, Jay K jay.kr...@cornell.edu wrote: We do need to be able to suspend/resume threads and get their context while suspended. We have two ways of doing this for pthreads platforms: send a signal and wait in the signal handler some use of semaphore here I think this semaphore thing runs afoul of typical usermode threading libraries, such as OpenBSD's. And apparently others e.g. FreeBSD and Darwin/MacOSX. On FreeBSD and Darwin we have custom code for suspend/resume. I think in some places it is based on the boehm gc. Is there anything in ports/devel/boehm-gc you could borrow? It does indeed do this type of operation and works pretty well on most arch we support (mips64* and the a.out arch being the notable exceptions). Please provide get/set/make/swapcontext. (and/or kernel threads.) As far as ports are concerned, the userland threading library (especially changed filedescriptor semantics) is I think the area causing us the biggest problems now. By contrast, though the ucontext.h functions would be nice to have, in the software I've ported, there's only one thing I've failed to port due to not having them...
developing openbsd?
I've looked all over www.openbsd.org. Any sort of guide/projects for new wannabe developers? (not new to programming) Just the bug list? Fix something send diffs? - Jay
Re: developing openbsd?
Ok, thanks all. Later. - Jay Date: Sun, 8 Aug 2010 12:14:30 +0100 From: vex...@gmail.com To: jay.kr...@cornell.edu CC: misc@openbsd.org Subject: Re: developing openbsd? On Sun, Aug 08, 2010 at 08:23:03AM +, Jay K wrote: I've looked all over www.openbsd.org. Any sort of guide/projects for new wannabe developers? Find something missing and implement it. I find myself sshing to linux boxes to valgrind things, so how about a leak checker for OpenBSD? And no.. not a valgrind port, somthing our own. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
java/amd64/4.7?
There is no: ftp://ftp.openbsd.org/pub/OpenBSD/4.7/packages/amd64/jre* I don't suppose I should use: ftp://ftp.openbsd.org/pub/OpenBSD/4.6/packages/amd64/jre* ? I'll maybe try building from source.. - Jay
Re: java/amd64/4.7?
Ah, thanks. But there is i386. And I only need jre, not jdk or plugin. I'll try from source within a few days (or maybe wait to see about 4.8). - Jay Date: Fri, 15 Oct 2010 16:44:41 +0200 Subject: Re: java/amd64/4.7? From: tomas.bod...@gmail.com To: jay.kr...@cornell.edu CC: misc@openbsd.org You missed important part which is http://www.openbsd.org/faq/faq13.html#javaplugin On Fri, Oct 15, 2010 at 1:14 PM, Jay K wrote: There is no: ftp://ftp.openbsd.org/pub/OpenBSD/4.7/packages/amd64/jre* I don't suppose I should use: ftp://ftp.openbsd.org/pub/OpenBSD/4.6/packages/amd64/jre* ? I'll maybe try building from source.. - Jay -- If youre good at something, never do it for free. The Joker
Re: java/amd64/4.7?
Ah, thanks. But there is i386. And I only need jre, not jdk or plugin. I'll try from source within a few days (or maybe wait to see about 4.8). You missed important part which is http://www.openbsd.org/faq/faq13.html#javaplugin So 1.7 requires 1.6. 1.6 requires 1.5. They all require manual downloading lots of files. And then it doesn't work anyway.. (SHA256) xalan-j_2_7_0-bin.tar.gz: OK === Extracting for jdk-1.5.0.16 /usr/local/bin/gtar: A lone zero block at 121752 replace control/make/Makefile? [y]es, [n]o, [A]ll, [N]one, [r]ename: NULL (assuming [N]one) *** Error code 1 Arg. Presumably I need to eithe redownload that file? Though I bet that won't fix it. Probably need to unpack, delete some file, hope it isn't used, repack.. - Jay
ports/root/make install
I'm building as root, but it'd probably be a nice option to automate: make ssh r...@localhost cd `pwd` make install Maybe it already is. - Jay
how to repeat messages about manual configuration
You know, installing ports/packages often gives you random manual configuration advise, like: === Installing jdk-1.6.0.03p9 from /usr/ports/packages/amd64/all/ jdk-1.6.0.03p9: ok --- +jdk-1.6.0.03p9 --- You may wish to add /usr/local/jdk-1.6.0/man to /etc/man.conf Use and distribution of this technology is subject to the Java Research License included herein. To use the Java plugin with Seamonkey or Firefox you must create a symbolic link (do not copy or hard link) from /usr/local/jdk-1.6.0/jre/plugin/amd64/ns7/libjavaplugin_oji.so to your local Mozilla plugins directory, which is found at ~/.mozilla/plugins/ or to the shared Mozilla plugins directory, which is found at /usr/local/lib/mozilla-plugins/ = 1) There should be a way to repeat all these messages for all installed packages. Maybe there already is. 2) Every time one of these is printed, the command that does #1 should be reported, possibly both for the specific packages, and all installed packages, or at least for all installed packages. (Don't make users remember what packages are installed or how to determine which are installed or which had the messages.) 3) You may wish to add /usr/local/jdk-1.6.0/man to /etc/man.conf isn't descriptive enough, I think, in that, when I looked into it, I didn't know what edit to make so I gave up. It should give a command. For that matter, so should the others. The Python messages give you actual copy/pastable commands. 3b) Maybe there should be a way to automate that further. But I suppose besides being optional, these things are also somewhat changable by user? I don't know. The Python ones surely could be automatic, without the -f. (ln -sf /usr/local/bin/python26 python or such) - Jay
Re: ports/root/make install
sudo won't work for me -- root password is *. I'll have to try it with ssh r...@localhost, which will work. Thanks, - Jay Date: Thu, 21 Oct 2010 12:30:32 -0500 Subject: Re: ports/root/make install From: sisso...@gmail.com To: jay.kr...@cornell.edu CC: misc@openbsd.org On Thu, Oct 21, 2010 at 12:20 PM, Jay K wrote: ssh r...@localhost cd `pwd` make install From man mk.conf: SUDO Command run by make(1) when doing certain operations requiring root privileges (e.g. the make install portion of make build). If set to /usr/bin/sudo, this allows one to run make build as a user other than root (assuming sudo is set up for that user).
password-less console-only access and ssh remote access?
My ideal setup would be: 1) no passwords (* in /etc/passwd or via vipw) 2) only ssh for remote access i.e. no password-based security, only something better 3) except console, where anyone should be able to login without any password (granted, I only have two users, root and jay) I haven't been able to achieve #3, so I compromise and have no console access at all, except maybe via single user. I really don't want security to be password-based. Hints? (This is on Linux, Solaris, NetBSD, Darwin, OpenBSD, FreeBSD; I've achieved #1 and #2 on all; presumably hints here only for OpenBSD.) Thanks, - Jay
Re: java/amd64/4.7?
ok, 1.5 built, 1.6 built, 1.7 in progress. Thanks.
I did say A for all during 15's extract.
Maybe there is a way to automate that.
I can remove 1.5 and 1.6 once 1.7 is there.
Still not understanding why i386 prebuilds this but amd64 does not.
- Jay
Date: Thu, 21 Oct 2010 12:00:24 +0300
Subject: Re: java/amd64/4.7?
From: tomas.bod...@gmail.com
To: jay.kr...@cornell.edu
CC: misc@openbsd.org
Didn't have any problems with that anytime before. Just 'sudo make
install' or 'make install' as root in that directory ('make package
BULK=Yes' is better) and when it asks for some file, I download it and
place in /usr/distfiles and start that command again.
On Thu, Oct 21, 2010 at 11:19 AM, Jay K wrote:
Ah, thanks. But there is i386. And I only need jre, not jdk or plugin.
I'll try from source within a few days (or maybe wait to see about 4.8).
You missed important part which is
http://www.openbsd.org/faq/faq13.html#javaplugin
So 1.7 requires 1.6.
1.6 requires 1.5.
They all require manual downloading lots of files.
And then it doesn't work anyway..
(SHA256) xalan-j_2_7_0-bin.tar.gz: OK
=== Extracting for jdk-1.5.0.16
/usr/local/bin/gtar: A lone zero block at 121752
replace control/make/Makefile? [y]es, [n]o, [A]ll, [N]one, [r]ename:
NULL
(assuming [N]one)
*** Error code 1
Arg.
Presumably I need to eithe redownload that file?
Though I bet that won't fix it.
Probably need to unpack, delete some file, hope it isn't used, repack..
- Jay
--
If youre good at something, never do it for free. The Joker
Re: how to repeat messages about manual configuration
using binary packages is only recommend solution for apps. Just small of amounts must be compiled from ports like that jdk Understood and I usually do. (jdk isn't small! :)) The request was for both. This reminds me another request though. But I'll have to sit through the entire FAQ. When building a package from source, I want a way to prefer installing dependencies from prebuilt packages. What I did lately is see what it prints as the dependencies, control-c, manually install those binary packages, then come back and rerun the higher level source build. Or I just let it run a while and do build unnecessarily from source. Thanks, - Jay
Re: ports/root/make install
I thought it'd need me to enter it. And there isn't one. Thanks, - Jay Date: Thu, 21 Oct 2010 15:09:25 -0400 Subject: Re: ports/root/make install From: ted.unan...@gmail.com To: jay.kr...@cornell.edu CC: sisso...@gmail.com; misc@openbsd.org On Thu, Oct 21, 2010 at 1:33 PM, Jay K jay.kr...@cornell.edu wrote: sudo won't work for me -- root password is *. The root password has nothing to do with sudo.
Re: how to repeat messages about manual configuration
I want the messages to tell me how to get the repeat. If there any messages, I want the instructions repeated at the end as well (on how to get the messages, not the actual messages). pkg_add | tee pkg.out ?? I shouldn't have to. What if I'm developing in a split python 2.4/2.6 environment? Not saying That's why omit the -f. Roughly. Make all the symlinks if none of them are already there. Granted, if you are en route to setting up 2.4 and 2.6, then whoever goes first would be arbitrary. Possibly all this should be deferred to the end of whatever all you are installing and batched up, so it can be analyzed for conflicts, so both would be skipped. - Jay
Re: password-less console-only access and ssh remote access?
You can get almost the same thing by setting PasswordAuthentication to no in your sshd_config file, and hand out empty or ridiculously simple passwords for the console (honestly, who would forget yermomsawhore as a password?). How do I limit their use to the console? If say I ssh in as non-root and then login root? ssh surely isn't the sole gatekeeper for login? (Granted, I am NOT running ftpd or telnetd; though at some point I'd like smbd/nfsd, hopefully both secure and convenient, hopefully using ssh somehow...). Thanks, - Jay
Re: password-less console-only access and ssh remote access?
Tomas, I don't understand. If I chroot then I can't do much at all right? Unless I replicate/link like the entire system, minus login. su/wheel group/sudo doesn't prevent simple running of login and typing the root password, right? Am I missing something? Maybe that ssh-only access to myself is good enough? Once I am me on the machine, there's no need for an obstacle to be root? And then su from there to root? I don't need to ssh as root? But if I allow others to ssh in, and don't limit them with chroot, then a password is needed. They won't be able to su/sudo, but they can still login. Right? So I'm back to the earlier point. Thanks, - Jay Date: Fri, 22 Oct 2010 13:11:44 +0300 Subject: Re: password-less console-only access and ssh remote access? From: tomas.bod...@gmail.com To: jay.kr...@cornell.edu CC: bret.lamb...@gmail.com; misc@openbsd.org On Fri, Oct 22, 2010 at 1:01 PM, Jay K wrote: You can get almost the same thing by setting PasswordAuthentication to no in your sshd_config file, and hand out empty or ridiculously simple passwords for the console (honestly, who would forget yermomsawhore as a password?). How do I limit their use to the console? If say I ssh in as non-root and then login root? You can chroot those logins and why they need root? You don't need to allow use of su for them, they don't need to be in wheel group and you can set in sudo only 'must need' apps for them. ssh surely isn't the sole gatekeeper for login? (Granted, I am NOT running ftpd or telnetd; though at some point I'd like smbd/nfsd, hopefully both secure and convenient, hopefully using ssh somehow...). Thanks, - Jay
Re: password-less console-only access and ssh remote access?
Tomas, I don't understand. If I chroot then I can't do much at all right? Unless I replicate/link like the entire system, minus login. su/wheel group/sudo doesn't prevent simple running of login and typing the root password, right? Am I missing something? Maybe that ssh-only access to myself is good enough? Once I am me on the machine, there's no need for an obstacle to be root? And then su from there to root? I don't need to ssh as root? But if I allow others to ssh in, and don't limit them with chroot, then a password is needed. They won't be able to su/sudo, but they can still login. Right? So I'm back to the earlier point. Thanks, - Jay Date: Fri, 22 Oct 2010 13:11:44 +0300 Subject: Re: password-less console-only access and ssh remote access? From: tomas.bod...@gmail.com To: jay.kr...@cornell.edu CC: bret.lamb...@gmail.com; misc@openbsd.org On Fri, Oct 22, 2010 at 1:01 PM, Jay K wrote: You can get almost the same thing by setting PasswordAuthentication to no in your sshd_config file, and hand out empty or ridiculously simple passwords for the console (honestly, who would forget yermomsawhore as a password?). How do I limit their use to the console? If say I ssh in as non-root and then login root? You can chroot those logins and why they need root? You don't need to allow use of su for them, they don't need to be in wheel group and you can set in sudo only 'must need' apps for them. ssh surely isn't the sole gatekeeper for login? (Granted, I am NOT running ftpd or telnetd; though at some point I'd like smbd/nfsd, hopefully both secure and convenient, hopefully using ssh somehow...). Thanks, - Jay
Re: password-less console-only access and ssh remote access?
Turn off sudo and don't put users you don't want to have root in the wheel group. I find what you want to be questionable though. But can't they still run login? Why questionable? I want security and convenience. I don't consider passwords to be either. physical security + ssh is what I want. I've gotten by with just the second and being sure I don't need console access after initial setup (I've run systems like this quite a while now, including upgrading OpenBSD a few times on a few machines, and Debian 4.0=5.0) Thanks, - Jay
Re: java/amd64/4.7?
ok, 1.5 built, 1.6 built, 1.7 in progress. Thanks. 1.7 ultimately fails: /usr/ports/pobj/jdk-1.7.0.00/openjdk/hotspot/agent/src/os/bsd/StubDebuggerLoc al.c:153: error: redefinition of `throw_new_debugger_exception' /usr/ports/pobj/jdk-1.7.0.00/openjdk/hotspot/agent/src/os/bsd/StubDebuggerLoc al.c:33: error: `throw_new_debugger_exception' previously defined here /usr/ports/pobj/jdk-1.7.0.00/openjdk/hotspot/agent/src/os/bsd/StubDebuggerLoc al.c:163: error: redefinition of `Java_sun_jvm_hotspot_debugger_bsd_BsdDebuggerLocal_init0' /usr/ports/pobj/jdk-1.7.0.00/openjdk/hotspot/agent/src/os/bsd/StubDebuggerLoc al.c:43: error: `Java_sun_jvm_hotspot_debugger_bsd_BsdDebuggerLocal_init0' previously defined here /usr/ports/pobj/jdk-1.7.0.00/openjdk/hotspot/agent/src/os/bsd/StubDebuggerLoc al.c:168: error: redefinition of `Java_sun_jvm_hotspot_debugger_bsd_BsdDebuggerLocal_getAddressSize' / etc. but 1.6 should suffice, thanks. - Jay
Re: password-less console-only access and ssh remote access?
If I chroot then I can't do much at all right? Unless I replicate/link like the entire system, minus login. You sai'd that you want to limit them, not I. I just don't want them to be able to login as root. And I don't want a password for root. If they are on the console though, ok either way. That is a laxness I failed to mention would be ok. just test it. If your user is not in wheel then he can use login and enter root password, but even when he knows that password login will not enter root shell as you are not in wheel, but if you know root password then you don't need to play those games and you can destroy something directly ;-) I will maybe poke around more. But again, I don't want anything to depend on root password. It should be empty and still be secure -- only allow password login from console, not remote. Only allow ssh access remotely. And I making sense? I neither want to remember passwords nor have anyone be able to guess them. Which is almost a contradiction. If someone is at the physical console, they can do anything. So I should be able to login to the console w/o password. And remote access only via ssh. Since I haven't figured out how to configure this, instead I set the password to * which disallows any password-based login, including physical console. If I ever really need console access, but haven't lost remote access, I should be able to reboot remotely and then go to the machine and alter the boot command line like to use single user mode. I certainly reboot the machines remotely sometimes (e.g. for an upgrade). Though I haven't needed single user mode yet, in a long time. Thanks, - Jay
