When you have a hosted machine, you need three tings. 1: That the system never require console access 2: No console access requirement 3: See 1 and 2 Mostly Gentoo handles this fine, the boot script can take quite a beating before it goes to hell, the weak spot is sshd thats part of /usr. One disk in my hosted server just crashed, it has /boot and / running raid1, so the machine could reboot and the startup script gracefully handled that /var /usr and friends was gone, but sshd is in /usr/bin/sshd so it wasn't able to startup. Would be nice having sshd having a USE flag to allow it to be installed in /bin, /sbin, /lib. Reproducible: Always Steps to Reproduce: 1. raid1 /boot and /, but not /usr 2. Take a sledsgehammer and tap one disk until it dies 3.reboot machine
I'm not sure that people who use the static OpenSSH has issues with it being in /usr. If you compile a static for an USB stick or a CD-ROM, or a simple recovery partition, your most likely is not going to have a mounted /usr anyway, so I think we shouldn't change the behavior, it might just cause problems for someone having custom recovery disk creation scripts. I could create a shadow /usr that only exist when the real /usr doesn't mount, with sshd. So I'm not sure modifying static compiled OpenSSH is the way to go. --datadir=/usr/share/openssh Where to put it's data? forced no pam support. No /usr/bin/sshd for normal operation. Compile openSSH normaly and install in /usr, then compile a second version based on static, that install to the root partition (non mounted /usr).
USE=static should definitely not imply this behavior i imagine EXTRA_ECONF=--prefix=/ should work ...
Well, since the closer didn't bother saying why it's closed and there is no way for me to tell if he just read the summary or he actually bothered to read up on the thread to get a clue. I'm going to reopen it with a Summary that better reflects what I requested.
i already made a statement in comment #2 i gave you a way to workaround it so unless you can propose a solution that doesnt suck, the bug gets closed
(In reply to comment #4) > i already made a statement in comment #2 > > i gave you a way to workaround it so unless you can propose a solution that > doesnt suck, the bug gets closed Please, thats not a workaround, OpenSSH doesn't work with the established standard for the root file structure and having a static OpenSSH isn't very practical for normal operations. A solution is needed that allows for *NORMAL* OpenSSH operation and for a recovery option in case of issues. If I had all the answers I would have posted them, I posted here in the hopes that we could look at the idea and come up with a solution to enhance "No/limited console operation" of Gentoo Linux, but as always all you get around here is the usual pig headed and piss poor attitude against everyone else. If the enhancement of "no/limited console operation" isn't of interest to the Gentoo project, then thats fine with me, just because I find it of value, doesn't make me think everyone else can't live without my ideas, but you didn't reject the basic idea or provide any other useful feedback to give me an idea of whatever I'm totally waisting my time or if there is actually an interest in this. I did make suggestions that you never bothered to give intelligent feedback to. Having the OpenSSH package maintain the recovery sshd directly is a far more manageable solution, whatever it's better done as a separate ebuild than a USE flag is where your supposed expertise was of value to me. Whatever it should be a loop back device file or installed under the mounted usr, is insignificant implemention details we will get to after we have established whatever there is a project to work on at all.
what you're proposing would be useful to a minority of people out there (having /usr on a separate partition is not common convention by any means) and would require quite a bit of overhead considering all the things openssh links against a better package to look at would be dropbear since it provides a very small ssh server and client without any external library dependencies developer time is limited ... do i have interest in putting something like this together ? not really ... but that doesnt preclude you from doing it. start developing support for like a USE=recovery flag. either way, interesting project developments do not happen on bugzilla ... this is a place for reporting bugs, not hammering out projects. that is why we have a developer mailing list.
(In reply to comment #6) > what you're proposing would be useful to a minority of people out there > (having /usr on a separate partition is not common convention by any means) Now thats really useful to know, since pretty much everything written down uses /usr on a separate partition, I thought that was normal. > developer time is limited ... do i have interest in putting something like this > together ? not really ... but that doesnt preclude you from doing it. My time is valuable and if I can't get a temperature check on an idea, I don't bother waisting my time on it. OpenSSH change is just a trial for a much larger project that would involve kernel, grub and many other areas to be enhanced for headless operation. I could spend years on this before I get all the changes I've planned accepted. If most of my time is going to be waisted just on issues like this thread originally. Then why bother sharing it at all. I'm sure I can hack this together in minutes instead of years if I don't have to consider anyone but myself. You talk about valuable developer time, but as far as I can tell a lot of self inflicted pain is being done here, by pushing away outsider contributions that could become a valuable resource. At least I've seen Gentoo devs threat other Gentoo devs as shit too, maybe it's a sick compliment, but I don't deal well with that kind of social structure, I usually give a high level of respect to strangers up front, and then let there actions dynamically adjust where things goes from there. I don't care if 99.9% is dickheads, as long as there is any left that actually could deserve respect, everyone gets the benefit of the doubt up front. > start > developing support for like a USE=recovery flag. either way, interesting > project developments do not happen on bugzilla ... this is a place for > reporting bugs, not hammering out projects. that is why we have a developer > mailing list. Then this is the only bugzilla where the enhancement feature is enabled, but considered bad form, that I've used in the past 15+ years.
Gentoo uses bugzilla as a tracking utility, not as a discussion forum ... discussions happen in the much more appropriate forum of mailing lists and once things have been hammered out, it gets moved to bugzilla ... there are other cases where the severity of enhancement in the context of a tracker makes sense as well (stable requests, version bump, etc...)
