Re: ZFS Boot Menu

[Teske, Devin]

On Sep 30, 2013, at 6:20 AM, Volodymyr Kostyrko wrote:

> 29.09.2013 00:30, Teske, Devin wrote:
>> Interested in feedback, but moreover I would like to see who is
>> interested in tackling this with me? I can't do it alone... I at least
>> need testers whom will provide feedback and edge-case testing.
> 
> Sign me in, I'm not fluent with forth but testing something new is always fun.
> 

Cool; to start with, do you have a virtual appliance software like VMware or
VirtualBox? Experience with generating ZFS pools in said software?

I think that we may have something to test next month.

Right now, we're working on the ability of bsdinstall(8) to provision "Boot on
ZFS" as a built-in functionality.

This feature (when in; projected for 10.0-BETA1) will make testing the Forth
enhancements easier (IMHO).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

ZFS Boot Menu

[Teske, Devin]

In my recent interview on bsdnow.tv, I was pinged on BEs in Forth.

I'd like to revisit this.

Back on Sept 20th, 2012, I posted some pics demonstrating what
exactly code that was in HEAD (at the time) was/is capable of.

These three pictures (posted the same day) tell a story:
1. You boot to the menu: http://twitpic.com/b1eswi/full
2. You select option #5 to get here: http://twitpic.com/b1etyb/full
3. You select option #2 to get here: http://twitpic.com/b1ew47/full

I've just (today) uploaded the /boot/menu.rc file(s) that I used to create
those pictures:

http://druidbsd.cvs.sf.net/viewvc/druidbsd/zfsbeastie/

NB: There's a README file to go along with the files.

HINT: diff -pu menu.rc.1.current-head menu.rc.2.cycler
HINT: diff -pu menu.rc.1.current-head menu.rc.2.dynamic-submenu

Interested in feedback, but moreover I would like to see who is
interested in tackling this with me? I can't do it alone... I at least
need testers whom will provide feedback and edge-case testing.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Trying to use /bin/sh

[Teske, Devin]

On Sep 28, 2013, at 12:41 PM, Matthew D. Fuller wrote:

> On Sat, Sep 28, 2013 at 04:36:03PM + I heard the voice of
> Teske, Devin, and lo! it spake thus:
>> 
>> xterm -sb -sl 400 -ls -r -si -sk -fn "-misc-fixed-medium-r-*-*-15-*"
> ^^^
> 

For those with variable-width fonts in their Mail Reader...

He highlighted "-ls" which stands for "login shell"; xterm(1).


> being the operative bit.  Or setting loginShell in resources; that way
> you don't have to change any invocations anywhere.
> 

Hadn't realized you could do that... excellent! Thanks for the tip on
setting that as a resource.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

bash_profile, tcshrc, etc... Oh My!

[Teske, Devin]

"Trying to use /bin/sh" thread inspired me to check my home-dir goodies into 
CVS:

http://druidbsd.cvs.sf.net/viewvc/druidbsd/home/

Just thought I'd share. There's some cool stuff if you want to have some fun.
-- 
Cheers,
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Trying to use /bin/sh

[Teske, Devin]

On Sep 28, 2013, at 1:12 AM, Stefan Esser wrote:

> Am 28.09.2013 00:14, schrieb Jilles Tjoelker:
>> sh's model of startup files (only login shells use startup files with
>> fixed names, other interactive shells only use $ENV) assumes that every
>> session will load /etc/profile and ~/.profile at some point. This
>> includes graphical sessions. The ENV file typically contains only shell
>> options, aliases, function definitions and unexported variables but no
>> environment variables.
>> 
>> Some graphical environments actually source shell startup files like
>> ~/.profile when logging in. I remember this from CDE for example. It is
>> important to have some rule where this should happen to avoid doing it
>> twice or never in "strange" configurations. As a workaround, I made
>> ~/.xsession a script interpreted by my login shell and source some
>> startup files. A problem here is that different login shells have
>> incompatible startup files.
> 
> I used to modify Xsession to do the final exec with a forced login
> shell of the user. This worked for users of all shells.
> 
> The script identified the shell to use and then used argv0 to start
> a "login shell" to execute the display manager.
> 
> A simplified version of my Xsession script is:
> 
> --
> #!/bin/sh
> 
> LIB=/usr/local/lib
> 
> SH=$SHELL
> [ -n "$SH" ] || SH="/bin/sh"
> SHNAME=`basename $SH`
> 
> echo "exec $LIB/xdm/Xsession.real $*" | \
>   /usr/local/bin/argv0 $SH -$SHNAME
> --
> 
> The argv0 command is part of "sysutils/ucspi-tcp", BTW.
> 
> This script prepends a "-" to the name of the shell that is
> started to execute the real "Xsession", which had been renamed
> to Xession.real.
> 
> I know that the script could be further simplified by using "modern"
> variable expansion/substitution commands, but this script was in use
> some 25 years ago on a variety of Unix systems (SunOS, Ultrix, HP-UX)
> and I only used the minimal set of Bourne Shell facilities, then.
> 
> You may want a command to source standard profiles or environment
> settings before the final exec, in case the users shell does not
> load them.
> 

In my ~/.fvwm2rc file, this is how I launch an XTerm. This achieves the
goal of sourcing my profile scripts like a normal login shell while launching
XTerm(s) in the GUI.

   DestroyFunc FvwmXTerm
   AddToFunc   FvwmXTerm
   PipeRead '\
cmd="/usr/bin/xterm";   \
[ -x "${cmd}" ] || cmd="/usr/X11R6/bin/xterm";  \
[ -x "${cmd}" ] || cmd="xterm"; \
cmd="${cmd} -sb -sl 400";   \
cmd="${cmd} -ls";   \
cmd="${cmd} -r -si -sk";\
cmd="${cmd} -fn \\"-misc-fixed-medium-r-*-*-15-*\\"";   \
echo "+ I Exec exec ${cmd}"'

Essentially producing an XTerm invocation of:

xterm -sb -sl 400 -ls -r -si -sk -fn "-misc-fixed-medium-r-*-*-15-*"

And everytime I launch an XTerm with that, I get my custom prompt set
by ~/.bash_profile.

Of course, I'm also a TCSH user, so when I flop over to tcsh, I also get
my custom prompt set by ~/.tcshrc

But failing that... you could actually make your XTerm a login shell with:

xterm -e login

But of course, then you're looking at having to enter credentials.

Perhaps it's just a matter of getting your commands into the right file...

.bash_profile for bash and .tcshrc for tcsh.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Should process run under chroot(8) still see mounts on the original system?

[Teske, Devin]

On Jul 23, 2013, at 4:31 PM, Mateusz Guzik wrote:

> On Tue, Jul 23, 2013 at 04:17:02PM -0700, Yuri wrote:
>> Currently, mount directories as shown by mount(8) command and
>> /compat/linux/dev/mounts from linprocfs(5) still show the original
>> mount points as other non-chrooted processes see.
>> So, when some program run under chroot tries to read the mount
>> points and do something with them it would likely fail because those
>> paths aren't what the process actually sees in its file system.
>> 
>> There are two situations: one when the process was started already
>> chrooted (like with command chroot(8)), and another one is when
>> process calls chroot(2) itself. Currently system seems to not
>> differentiate between these two cases.
>> 
>> It looks reasonable to automatically modify mount(8) and
>> linprocfs(5) results when the process has been started already
>> chrooted and this process is (practically) always unaware of chroot.
>> So that when chroot was in place when execve(2), kernel could set
>> the boolean flag and later adjust mount directories accordingly.
>> 
> 
> While changing the code to do what you propose would not be that
> difficult, I don't see the point. In cases like this you can simply
> jail(2) and there you go (or at least this should work just fine).
> 
> Of course then you may have some unnecessary separation but that I
> believe can be simply worked out if it turns out to be problematic.
> 

What the OP wants is implemented for jails via the sysctl ``knob'' 
"security.jail.enforce_statfs"

It can have one of three values.

0 = show nothing from the base in jailed df(1) output
2 = show everything from the base in jailed df(1) output

What you want sounds like the number in-between:

1 = show only mount points from the base that appear within the jail *and* make 
the jailed df(1) output show a modified path that is rooted in said jail
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Announcing: nuOS 0.0.9.1b1 - a whole NEW FreeBSD distro, NOT a fork

[Teske, Devin]

On Jul 8, 2013, at 11:43 AM, Chad J. Milios wrote:

> On 07/08/13 00:12, Teske, Devin wrote:
>> On Jul 7, 2013, at 2:58 PM, Chad J. Milios wrote:
>> [snip]
>> 
>>>/etc is now a ZFS dataset of its own
>>>How did we do it?
>>>Decades of conventional wisdom says /etc must be on /.
>>>Check it out, discuss the whys and the trade-offs.
>> Well, I see in nu_install on GitHub how you're doing it:
>> 
>> You added:
>> 
>>  init_script="/boot/init.sh"
>> 
>> to /boot/loader.conf, wich -- among other things -- does these two 
>> interesting things (variable names changed to make things more clear):
>> 
>> zfs rollback -r $zfs/swap/host@blank
>> NOTE: $zfs is equal to $( /bin/kenv vfs.root.mountfrom ) minus the leading 
>> "zfs:"
>> 
>> and
>> 
>> zfs mount $zpool/etc
>> NOTE: $zpool is equal to $zfs from above, leading up to (but not including) 
>> the first slash (/).
>> 
>> Cute. Have to say I wasn't aware of the init_script feature of 
>> loader.conf(5). Not bad.
> 
> We also had to put one file into the etc directory on the / "beneath" the 
> /etc mount so that /sbin/init can read it before /etc is mounted. There were 
> two or three ways we could do that and each has a tradeoff.
> 

I've been bitten by that.

Getting access to that file that's "beneath" once you've booted the system can 
be ... less than easy.

I'm interested in your cost/benefit points of having /etc a separate filesystem.

On the face of it, I want to say that "/etc" is (or at least contains) the 
"core identity" of the machine (and to a lesser extent -- because this is BSD 
after-all -- /usr/local/etc). In my mind, /etc and /usr/local/etc *are* the 
machine (metaphorically speaking), so the merits of having it as a separate 
filesystem are weighed against your desired topology.

If you want to bunch of machines to look and/or act differently, then a shared 
/etc is precisely what you want. However, without allowing minor changes (ala 
ZFS clone/snapshot or by way of UnionFS), you'll quickly find that the only way 
to cope is with role-based scripting in /etc/rc.conf (it is after-all a shell 
script) or complicated abstraction layers (for example, using netgraph eiface 
devices with the jail-name inside them so that rc.conf have have jail-specific 
ifconfig_* lines). But I digress.

I think the better solution to your loading of files "beneath" the eventual 
/etc filesystem is to throw away the ZFS snapshot/clone method and instead move 
to a UnionFS approach for /etc.

If you use UnionFS for your /etc, then what you do is for each of the machines 
that you want *that* /etc to appear, you do something like:

(as root) mount_unionfs -o below /etc /other/etc

Now /other/etc (assuming it was empty before) looks exactly like /etc.

Pros: With "rm -f ; rm -W " (in /other/etc) you can reclaim a file 
from the underlying /etc. ZFS does not allow you to revert a single file (you 
can revert the entire volume or filesystem, but not a single file).

Cons: The advantage of having /etc as a ZFS filesystem is probably going to be 
the compressratio. Using something like lzjb compression on your /etc directory 
is beneficial (not as beneficial has say /var/log, but by means of having 
mostly text files, /etc should compress nicely). But... if you *really* need to 
compress your /etc (that is to say, you're hard-up enough for space that you 
need the little-savings that you'll gain from compressing /etc), then you're 
also hard-up enough that you should just set compression on the entire 
filesystem (nullifying your need to make /etc a separate filesystem -- /etc 
would get the compression feature from the underlying root filesystem; whatever 
that is -- zfs filesystem, zpool, zvol, etc.). So again, UnionFS looks like a 
win unless you *really* want to set separate filesystem features for /etc that 
you don't set elsewhere.

Were you perhaps after a zfs-/etc for some other reason? because there are 
other reasons that I'm not getting into. For example, using sysutils/zxfer to 
make backups of the /etc directory of an entire cloud of machines to a single 
host. If you don't have /etc as a separate filesystem (and all you want is 
/etc) then a ZFS stream is of course out of the question and you'll have to 
resort to rsync. I personally think zxfer is more efficient than rsync but I 
haven't done the calculations yet to prove it (but it feels like it -- 
incremental snapshot transfers are pretty darned quick).


> What we did (mv /etc/login.conf.db /boot/etc; ln -s ../boot/etc/login.conf.db 
> /etc/login.conf.db) has the unde

Re: Announcing: nuOS 0.0.9.1b1 - a whole NEW FreeBSD distro, NOT a fork

[Teske, Devin]

On Jul 7, 2013, at 2:58 PM, Chad J. Milios wrote:
[snip]

>/etc is now a ZFS dataset of its own
>How did we do it?
>Decades of conventional wisdom says /etc must be on /.
>Check it out, discuss the whys and the trade-offs.

Well, I see in nu_install on GitHub how you're doing it:

You added:

init_script="/boot/init.sh"

to /boot/loader.conf, wich -- among other things -- does these two interesting 
things (variable names changed to make things more clear):

zfs rollback -r $zfs/swap/host@blank
NOTE: $zfs is equal to $( /bin/kenv vfs.root.mountfrom ) minus the leading 
"zfs:"

and

zfs mount $zpool/etc
NOTE: $zpool is equal to $zfs from above, leading up to (but not including) the 
first slash (/).

Cute. Have to say I wasn't aware of the init_script feature of loader.conf(5). 
Not bad.
-- 
Devin

NOTE: Paring down on the cross-posting (bad OP). Posting only to -hackers@ (as 
it seems to be the right place to post disseminating analysis).

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Shell variables containing output redirects

[Teske, Devin]

On Jun 20, 2013, at 9:11 AM, Teske, Devin wrote:

> 
> On Jun 20, 2013, at 9:04 AM, Teske, Devin wrote:
> 
>> 
>> On Jun 20, 2013, at 7:57 AM, Alexander Yerenkow wrote:
>> 
>>> Hello all!
>>> 
>>> I have a problem with port JBoss72, which tries to behave as long-standing
>>> port jboss5:
>>> 
>>> http://svnweb.freebsd.org/ports/head/java/jboss5/files/jboss5.in?revision=302141&view=markup
>>> 
>>> 
>>> 
>>> In rc run script there is such line:
>>> 
>>> %%APP_SHORTNAME%%_logging="${%%APP_SHORTNAME%%_logging:-">>
>>> ${%%APP_SHORTNAME%%_logdir}/stdout.log 2>>
>>> ${%%APP_SHORTNAME%%_logdir}/stderr.log"}"
>>> 
>>> Which provides way to overwrite default log location in /etc/rc.conf.
>>> 
>>> But this not working at all, all these redirects treated as simple
>>> parameters for run script.
>>> 
>>> I made small test, to show my problem:
>>> 
>>> #!/bin/sh
>>> 
>>> logfile="supposed-to-be.log"
>>> log=">> ${logfile}"
>>> echo "a1" >> ${logfile}
>>> echo "a2" ${log}
>>> cmd="echo \"a3\" ${log}"
>>> echo $cmd
>>> $cmd
>>> more ${logfile}
>>> 
>>> Here's execution output:
>>> 
>>> # ./t1.sh
>>> a2 >> supposed-to-be.log
>>> echo "a3" >> supposed-to-be.log
>>> "a3" >> supposed-to-be.log
>>> a1
>>> 
>>> 1. My question is - Which are correct way to specify such redirects to be
>>> overridden?
>>> 
>> 
>> If you must have a conditional redirect in the above manner (in which the 
>> redirect syntax is part of a variable):
>> 
>> to_foofile=">> foofile"
>> eval echo \"a1\" $to_foofile
>> 
>> The shell will do a first-pass on the arguments, so what "eval" sees as 
>> arguments are:
>> 
>> echo "a1" >> foofile
>> 
>> And thus, eval does what it does best… evaluates the expressions as a set of 
>> shell statements.
>> 
>> NOTE: The rc script probably assumed bash and was ported from another system 
>> where /bin/sh was indeed bash (but in FreeBSD, /bin/sh is not bash and is 
>> much more strict in adhering to POSIX standards).
>> 
>> However, I can't in all earnest recommend that approach as a method of 
>> conditional logging when there are so many better solutions.
>> 
>> Here's one of my favorites for quick-and-dirty conditional logging:
>> 
>> ===
>> 
>> #!/bin/sh
>> 
>> if : some condition to enable debugging; then
>>  exec 3>>/tmp/log.stdout 4>>/tmp/log.stderr
>> else
>>  exec 3>&1 4>&2
>> fi
>> 
>> echo "a1" 1>&3 2>&4
>>  # "a1" ends up in /tmp/log.stdout
>> 
>> ls /nosuchfile 1>&3 2>&4
>>  # You get in /tmp/log.stderr: "ls: /nosuchfile: No such file or 
>> directory"
>> 
>> ===
>> 
> 
> Yeah… don't do that… the moment I hit send, it dawned on me that the extra 
> file-descriptor (however cute), is entire unnecessary…
> 
> ===
> 
> #!/bin/sh
> if : some condition to enable debugging; then
>   exec 1>>/tmp/log.stdout 2>>/tmp/log.stderr
> fi
> echo d1
>   # if debugging, goes to /tmp/log.stdout
>   # if no debugging, goes to console
> ls /nosuchfile
>   # if debugging, an error goes to /tmp/log.stderr
>   # if no debugging, error goes to console
> 
> ===
> 
> 
> 
>> So rather than having to prefix "eval" to every command *and* escape all the 
>> quotes and expansions… the above instead changes from (old) attempting to 
>> use a conditional redirect syntax (by way of $logging variable) to 
>> (new/above) having every command redirect stdout/stderr but having the 
>> destinations of the redirect change based on some pre-condition.
>> 
>> 
>> 
>>> 2. tomcat6.in, rubyrep.in, tclhttpd.in, geoserver.in, and many more rc
>>> scripts from ports are using something like this:
>>> 
>>> log_args=">> ${tclhttpd_stdout_log} 2>> ${tclhttpd_stderr_log} "
>>> 
>>> and after that use $log_args.
>>> 
>>> Are they silently broken, or am I missing something?
>>> 
>> 
>> I would call that broken 

Re: Shell variables containing output redirects

[Teske, Devin]

On Jun 20, 2013, at 9:04 AM, Teske, Devin wrote:

> 
> On Jun 20, 2013, at 7:57 AM, Alexander Yerenkow wrote:
> 
>> Hello all!
>> 
>> I have a problem with port JBoss72, which tries to behave as long-standing
>> port jboss5:
>> 
>> http://svnweb.freebsd.org/ports/head/java/jboss5/files/jboss5.in?revision=302141&view=markup
>> 
>> 
>> 
>> In rc run script there is such line:
>> 
>> %%APP_SHORTNAME%%_logging="${%%APP_SHORTNAME%%_logging:-">>
>> ${%%APP_SHORTNAME%%_logdir}/stdout.log 2>>
>> ${%%APP_SHORTNAME%%_logdir}/stderr.log"}"
>> 
>> Which provides way to overwrite default log location in /etc/rc.conf.
>> 
>> But this not working at all, all these redirects treated as simple
>> parameters for run script.
>> 
>> I made small test, to show my problem:
>> 
>> #!/bin/sh
>> 
>> logfile="supposed-to-be.log"
>> log=">> ${logfile}"
>> echo "a1" >> ${logfile}
>> echo "a2" ${log}
>> cmd="echo \"a3\" ${log}"
>> echo $cmd
>> $cmd
>> more ${logfile}
>> 
>> Here's execution output:
>> 
>> # ./t1.sh
>> a2 >> supposed-to-be.log
>> echo "a3" >> supposed-to-be.log
>> "a3" >> supposed-to-be.log
>> a1
>> 
>> 1. My question is - Which are correct way to specify such redirects to be
>> overridden?
>> 
> 
> If you must have a conditional redirect in the above manner (in which the 
> redirect syntax is part of a variable):
> 
> to_foofile=">> foofile"
> eval echo \"a1\" $to_foofile
> 
> The shell will do a first-pass on the arguments, so what "eval" sees as 
> arguments are:
> 
> echo "a1" >> foofile
> 
> And thus, eval does what it does best… evaluates the expressions as a set of 
> shell statements.
> 
> NOTE: The rc script probably assumed bash and was ported from another system 
> where /bin/sh was indeed bash (but in FreeBSD, /bin/sh is not bash and is 
> much more strict in adhering to POSIX standards).
> 
> However, I can't in all earnest recommend that approach as a method of 
> conditional logging when there are so many better solutions.
> 
> Here's one of my favorites for quick-and-dirty conditional logging:
> 
> ===
> 
> #!/bin/sh
> 
> if : some condition to enable debugging; then
>   exec 3>>/tmp/log.stdout 4>>/tmp/log.stderr
> else
>   exec 3>&1 4>&2
> fi
> 
> echo "a1" 1>&3 2>&4
>   # "a1" ends up in /tmp/log.stdout
> 
> ls /nosuchfile 1>&3 2>&4
>   # You get in /tmp/log.stderr: "ls: /nosuchfile: No such file or 
> directory"
> 
> ===
> 

Yeah… don't do that… the moment I hit send, it dawned on me that the extra 
file-descriptor (however cute), is entire unnecessary…

===

#!/bin/sh
if : some condition to enable debugging; then
exec 1>>/tmp/log.stdout 2>>/tmp/log.stderr
fi
echo d1
# if debugging, goes to /tmp/log.stdout
# if no debugging, goes to console
ls /nosuchfile
# if debugging, an error goes to /tmp/log.stderr
# if no debugging, error goes to console

===



> So rather than having to prefix "eval" to every command *and* escape all the 
> quotes and expansions… the above instead changes from (old) attempting to use 
> a conditional redirect syntax (by way of $logging variable) to (new/above) 
> having every command redirect stdout/stderr but having the destinations of 
> the redirect change based on some pre-condition.
> 
> 
> 
>> 2. tomcat6.in, rubyrep.in, tclhttpd.in, geoserver.in, and many more rc
>> scripts from ports are using something like this:
>> 
>> log_args=">> ${tclhttpd_stdout_log} 2>> ${tclhttpd_stderr_log} "
>> 
>> and after that use $log_args.
>> 
>> Are they silently broken, or am I missing something?
>> 
> 
> I would call that broken if the invocation line at the top of the script is 
> #!/bin/sh (it may not be broken if you instead see something like 
> "#!/usr/bin/env bash").
> 
> 
> 
> 
>> 3. Should I build up $cmd, and run
>> eval "$cmd" - would this be nice ro dirty hack?
>> 
> 
> Nah… just go through and replace "$log_args" with either "1>&3 2>&4" or ">&3 
> 2>&4" (the leading 1 on ">&" in the first option is actually the implied 
> default, so you can omit i

Re: Shell variables containing output redirects

[Teske, Devin]

On Jun 20, 2013, at 7:57 AM, Alexander Yerenkow wrote:

> Hello all!
> 
> I have a problem with port JBoss72, which tries to behave as long-standing
> port jboss5:
> 
> http://svnweb.freebsd.org/ports/head/java/jboss5/files/jboss5.in?revision=302141&view=markup
> 
> 
> 
> In rc run script there is such line:
> 
> %%APP_SHORTNAME%%_logging="${%%APP_SHORTNAME%%_logging:-">>
> ${%%APP_SHORTNAME%%_logdir}/stdout.log 2>>
> ${%%APP_SHORTNAME%%_logdir}/stderr.log"}"
> 
> Which provides way to overwrite default log location in /etc/rc.conf.
> 
> But this not working at all, all these redirects treated as simple
> parameters for run script.
> 
> I made small test, to show my problem:
> 
> #!/bin/sh
> 
> logfile="supposed-to-be.log"
> log=">> ${logfile}"
> echo "a1" >> ${logfile}
> echo "a2" ${log}
> cmd="echo \"a3\" ${log}"
> echo $cmd
> $cmd
> more ${logfile}
> 
> Here's execution output:
> 
> # ./t1.sh
> a2 >> supposed-to-be.log
> echo "a3" >> supposed-to-be.log
> "a3" >> supposed-to-be.log
> a1
> 
> 1. My question is - Which are correct way to specify such redirects to be
> overridden?
> 

If you must have a conditional redirect in the above manner (in which the 
redirect syntax is part of a variable):

to_foofile=">> foofile"
eval echo \"a1\" $to_foofile

The shell will do a first-pass on the arguments, so what "eval" sees as 
arguments are:

echo "a1" >> foofile

And thus, eval does what it does best… evaluates the expressions as a set of 
shell statements.

NOTE: The rc script probably assumed bash and was ported from another system 
where /bin/sh was indeed bash (but in FreeBSD, /bin/sh is not bash and is much 
more strict in adhering to POSIX standards).

However, I can't in all earnest recommend that approach as a method of 
conditional logging when there are so many better solutions.

Here's one of my favorites for quick-and-dirty conditional logging:

===

#!/bin/sh

if : some condition to enable debugging; then
exec 3>>/tmp/log.stdout 4>>/tmp/log.stderr
else
exec 3>&1 4>&2
fi

echo "a1" 1>&3 2>&4
# "a1" ends up in /tmp/log.stdout

ls /nosuchfile 1>&3 2>&4
# You get in /tmp/log.stderr: "ls: /nosuchfile: No such file or 
directory"

===

So rather than having to prefix "eval" to every command *and* escape all the 
quotes and expansions… the above instead changes from (old) attempting to use a 
conditional redirect syntax (by way of $logging variable) to (new/above) having 
every command redirect stdout/stderr but having the destinations of the 
redirect change based on some pre-condition.



> 2. tomcat6.in, rubyrep.in, tclhttpd.in, geoserver.in, and many more rc
> scripts from ports are using something like this:
> 
> log_args=">> ${tclhttpd_stdout_log} 2>> ${tclhttpd_stderr_log} "
> 
> and after that use $log_args.
> 
> Are they silently broken, or am I missing something?
> 

I would call that broken if the invocation line at the top of the script is 
#!/bin/sh (it may not be broken if you instead see something like 
"#!/usr/bin/env bash").




> 3. Should I build up $cmd, and run
> eval "$cmd" - would this be nice ro dirty hack?
> 

Nah… just go through and replace "$log_args" with either "1>&3 2>&4" or ">&3 
2>&4" (the leading 1 on ">&" in the first option is actually the implied 
default, so you can omit it and go for the second option if you like; however 
since you can't say "exec 3>&" and have to say "exec 3>&1", I tend to think the 
first option is more explicitly-clear in what's going on with the 
file-descriptors).



> Thanks!
> 

No problem. Glad to help.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: /bin/sh => STDIN & functions, var scope messing

[Teske, Devin]

On May 31, 2013, at 10:59 AM, 
 wrote:

> Redirections > and >> don't put it in a subshell.

Correct. (note: I made no such insinuation; But thanks for clarifying for 
others that perhaps were not aware).


> Only pipe |, which means only STDIN affects/triggers this behaviour.
> Does < operator also does it, as it is also STDIN?
> 
> Anyway, I don't care for executing binaries, but I do care if that is part of 
> sh's code, as function is.
> It messes var scopes.
> 
> And finally if we take into account this:
> 
>> For example… in pc-sysinstall…
>> 
>> ./backend/functions-extractimage.sh-  tar cvf - . 2>/dev/null | tar -xpv 
>> -C ${FSMNT} ${TAROPTS} -f - 2>&1 | tee -a ${FSMNT}/.tar-extract.log
>> ./backend/functions-extractimage.sh:  if [ $? -ne 0 ]
>> 
>> That's a big no-no.
>> 
>> If your first tar (the initial lvalue to the first pipe) fails… but your 
>> second tar succeeds (rvalue to the first pipe)… you won't catch that failure 
>> in your checking of $?
>> 
>> Also, if the first tar succeeds, but the second tar fails, AND the final 
>> rvalue (the tee) succeeds… you also miss the error code.
>> 
>> I call this the "piped return-status conflation issue". Basically… anytime 
>> you want to check the return-status in shell… and you care about 
>> lvalue-failures in a pipe-chain… you must rewrite it to either:
>> 
>> (a) be aware of the problem (I've in the past written wrappers that will 
>> test the previous return status and abort the chain in such an event)
>> 
>> (b) undo the pipe-chain and store your results for incremental processing… 
>> checking the return status after each filter.
>> 
>> -- 
>> Devin
> 
> 
> sh's behaviour must be changed regarding piping
> 

If you're arguing we have to change sh's behavior to be more compliant, jilles 
already quoted XCU 2.12 (our shell is well within its right to run any/all 
lvalue/rvalue operands of a pipe in a sub-shell without contradicting the 
guidelines).

But if you're arguing that it has to change to make things better or easier… I 
don't know about that. Might just make people lulled into using a style that's 
non-portable. I'd like to keep things the way they are so that if you program 
for FreeBSD, you're inherently going to program in a fashion that is more 
portable.
-- 
Devin




>>> Curious. Which of the two behaviours is POSIXly correct?
>> 
>> Both. As per XCU 2.12 Shell Execution Environment, each command in a
>> multi-command pipeline may or may not be executed in a subshell
>> environment.
>> 
>> Behaviour different from our sh is most often encountered in the various
>> versions of the real Korn shell (ksh88 and ksh93), which execute the
>> last command in a pipeline in the current shell environment.
>> 
>> If things like  jobs | cat  work, that can also be explained using this
>> rule.
>> 
>> -- 
>> Jilles Tjoelker
>> 
> 
> 
> Domagoj Smolčić
> 
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 28, 2013, at 4:16 PM, Super Bisquit wrote:

In the case of firmware loaded systems, all of them aren't going to work with a 
single boot loader.


Uh…

On the surface, what you're talking about seems to be unrelated to the 
discussion at-hand.

Nobody said anything about unifying the boot loader.

We're talking about the installer… not the boot loader.

*usually* the installer doesn't care about how it got to its installation 
environment.

NOTE: I say *usually* because there *are* specialized situations like cobbler + 
mfsbsd + pc-sysinstall in which case the boot loader needs to provide certain 
information (which is then accessible through kenv(1)). That type of 
installation setup will fail if the specialized boot loader does not boot on 
the desired target installation platform *or* the boot loader that _does_ work 
on said platform doesn't provide the necessary information.

That being said… bsdinstall doesn't require special knowledge from the boot 
loader (to the best of my knowledge).

sysinstall didn't need special info from the boot loader either.

I don't see why talking about a unified installer has to include a discussion 
involving unifying the boot loader (a topic in my mind that is unattainable).
--
Devin






On Tue, May 28, 2013 at 1:15 PM, Teske, Devin 
mailto:devin.te...@fisglobal.com>> wrote:

On May 28, 2013, at 8:54 AM, Alfred Perlstein wrote:

On 5/28/13 7:49 AM, Nathan Whitehorn wrote:
On 05/27/13 23:36, Alfred Perlstein wrote:
On 5/27/13 6:53 PM, Nathan Whitehorn wrote:
On 05/27/13 20:40, Alfred Perlstein wrote:
On 5/27/13 2:23 PM, Bruce Cran wrote:
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran wrote:
Yes.
Is this a joke?

It probably /was/ too short a reply. Personally I think there should be a 
single UI and scripting interface across all platforms. We should try and get 
pc-sysinstall running on all of them first in case there's some problem that 
means it can't be done, in which case we'd need to use a different backend.


There are just going to be certain platforms that make it EASY to do cool 
things.  We should embrace that!  That's why there are different platforms!

Some are great for low power, others are great for graphics, cpu power, gpu, 
networking etc.

If we always go for the lowest common denominator then we are crippling all the 
platforms for no one's benefit.  Even if something CAN be done, if it is very 
difficult, or just never happening, then we can't limit everyone's experience 
based on the more difficult and/or resource strapped platforms.

It's just not good business.

Yes, and all of this cuts both ways: pc-sysinstall has no wireless setup 
support, for instance. Right now we support what we support because it is the 
most feature-complete thing we have, not just on tier-2 platforms but also on 
x86.

To bring this discussion back to the ground, the fact is that we lack an 
installer that has both internal support for ZFS and a UI. One of the reasons 
for this is that making a good expressive UI for ZFS is a non-trivial 
undertaking given its enormous flexibility. The bsdinstall partition editor has 
been written to be extensible for this, and several people have started writing 
code to do it, but no one ended up having time to finish. Probably a reasonable 
thing to do is to start with supporting only a minimal set of features. If 
anyone felt like actually writing this code, I'm sure it would be appreciated 
by all and be more productive than email exchanges.
-Nathan

I'm sure if there was a list of reasonable things, such as wireless then 
pc-sysinstall could be augmented.  This is the first I've heard of that.  All 
the other complaints have been based on portability.

Is that all that is required now, wireless?

There are more, as well. A partial list of missing features on both sides is 
here: 
https://wiki.freebsd.org/PCBSDInstallMerge<https://urldefense.proofpoint.com/v1/url?u=https://wiki.freebsd.org/PCBSDInstallMerge&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=BFNRw%2Fl9%2B28%2BnxLbdzO4ji0pUaEPGB%2BV9%2BaaBuFSGWM%3D%0A&s=3bbe977edd2b122e6d4bc08d7650eb11e412fe03c97b25b3aa86cbf4c96e9ba6>.
 Other major ones are IPv6 (maybe this has changed?) and no jail setup feature. 
Most of the existing disk partitioning code in pc-sysinstall, which is the only 
thing in a FreeBSD installer that is at all complicated, is also *extremely* 
fragile and needs in all likelihood to be entirely replaced. The merge effort 
stalled because of this kind of issue -- doing a "merge" rapidly became 
rewriting both from scratch.
-Nathan

Ah this is so cool.  I'll bring it up with the PCBSD folks today.

Thank you Nathan.


I had my own look at the pc-sysinstall and bsdinstall code and came to the same 
conclusions, plus some.

One of the biggest obstacles I se

Re: /bin/sh => STDIN & functions, var scope messing

[Teske, Devin]

On May 28, 2013, at 8:07 AM, Reid Linnemann wrote:

> 
> On May 28, 2013, at 7:00 AM, Ryan Stone  wrote:
> 
>> On Tue, May 28, 2013 at 5:48 AM, Václav Zeman  wrote:
>> Curious. Which of the two behaviours is POSIXly correct?
>> 
>> I believe that /bin/sh's behaviour is correct.  I don't know what shell the 
>> manpage is referring to, but it's not bash (bash does the same thing in a 
>> pipeline).  Perhaps it's referring to csh?  If that is the case that line is 
>> probably causing more confusion rather than alleviating it.
> 
> I believe it's referring to csh, possible ksh as well. I tried a similar 
> experiment with tcsh:
> 
> #!/bin/tcsh
> alias fn set var=12
> set var=
> echo $var
> yes | fn
> echo $var


I wonder why the sh(1) manual would be referring to csh(1).

CSH does more than this, so you know…

#!/bin/csh
true | true | false | true
# returns false

#!/bin/sh
true | true | false | true
# returns true

So not only must you be aware that sh(1) throws away variables assigned within 
a shell running as an rvalue to any pipe (because said statements are run in a 
sub-shell with a transient namespace initialized from the parent)…

You must also be aware that return status of an lvalue operand of a pipe is not 
retained along the chain. The entire chain is traversed (all rvalues of all 
pipes are invoked), but in sh(1) only the return status of last rvalue is 
returned.

I see this problem running rampant in the pc-sysinstall code.

For example… in pc-sysinstall…

./backend/functions-extractimage.sh-  tar cvf - . 2>/dev/null | tar -xpv -C 
${FSMNT} ${TAROPTS} -f - 2>&1 | tee -a ${FSMNT}/.tar-extract.log
./backend/functions-extractimage.sh:  if [ $? -ne 0 ]

That's a big no-no.

If your first tar (the initial lvalue to the first pipe) fails… but your second 
tar succeeds (rvalue to the first pipe)… you won't catch that failure in your 
checking of $?

Also, if the first tar succeeds, but the second tar fails, AND the final rvalue 
(the tee) succeeds… you also miss the error code.

I call this the "piped return-status conflation issue". Basically… anytime you 
want to check the return-status in shell… and you care about lvalue-failures in 
a pipe-chain… you must rewrite it to either:

(a) be aware of the problem (I've in the past written wrappers that will test 
the previous return status and abort the chain in such an event)

(b) undo the pipe-chain and store your results for incremental processing… 
checking the return status after each filter.

-- 
Devin

NOTE: I'm responding on another thread that is related to pc-sysinstall 
changes. In that thread, I didn't mention the above faux-pas of pc-sysinstall 
because I really do consider things like this to be secondary to the 
over-arching namespace and debugging issues.

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 28, 2013, at 8:54 AM, Alfred Perlstein wrote:

On 5/28/13 7:49 AM, Nathan Whitehorn wrote:
On 05/27/13 23:36, Alfred Perlstein wrote:
On 5/27/13 6:53 PM, Nathan Whitehorn wrote:
On 05/27/13 20:40, Alfred Perlstein wrote:
On 5/27/13 2:23 PM, Bruce Cran wrote:
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran wrote:
Yes.
Is this a joke?

It probably /was/ too short a reply. Personally I think there should be a 
single UI and scripting interface across all platforms. We should try and get 
pc-sysinstall running on all of them first in case there's some problem that 
means it can't be done, in which case we'd need to use a different backend.


There are just going to be certain platforms that make it EASY to do cool 
things.  We should embrace that!  That's why there are different platforms!

Some are great for low power, others are great for graphics, cpu power, gpu, 
networking etc.

If we always go for the lowest common denominator then we are crippling all the 
platforms for no one's benefit.  Even if something CAN be done, if it is very 
difficult, or just never happening, then we can't limit everyone's experience 
based on the more difficult and/or resource strapped platforms.

It's just not good business.

Yes, and all of this cuts both ways: pc-sysinstall has no wireless setup 
support, for instance. Right now we support what we support because it is the 
most feature-complete thing we have, not just on tier-2 platforms but also on 
x86.

To bring this discussion back to the ground, the fact is that we lack an 
installer that has both internal support for ZFS and a UI. One of the reasons 
for this is that making a good expressive UI for ZFS is a non-trivial 
undertaking given its enormous flexibility. The bsdinstall partition editor has 
been written to be extensible for this, and several people have started writing 
code to do it, but no one ended up having time to finish. Probably a reasonable 
thing to do is to start with supporting only a minimal set of features. If 
anyone felt like actually writing this code, I'm sure it would be appreciated 
by all and be more productive than email exchanges.
-Nathan

I'm sure if there was a list of reasonable things, such as wireless then 
pc-sysinstall could be augmented.  This is the first I've heard of that.  All 
the other complaints have been based on portability.

Is that all that is required now, wireless?

There are more, as well. A partial list of missing features on both sides is 
here: https://wiki.freebsd.org/PCBSDInstallMerge. Other major ones are IPv6 
(maybe this has changed?) and no jail setup feature. Most of the existing disk 
partitioning code in pc-sysinstall, which is the only thing in a FreeBSD 
installer that is at all complicated, is also *extremely* fragile and needs in 
all likelihood to be entirely replaced. The merge effort stalled because of 
this kind of issue -- doing a "merge" rapidly became rewriting both from 
scratch.
-Nathan

Ah this is so cool.  I'll bring it up with the PCBSD folks today.

Thank you Nathan.


I had my own look at the pc-sysinstall and bsdinstall code and came to the same 
conclusions, plus some.

One of the biggest obstacles I see is actually a high-level issue that I've 
self-identified through extensive work on bsdconfig (which is both a back-end 
and a front-end).

This is the issue of debugging and namespaces.

I've sat down and made lists of other issues… but when I review, I find these 
issues to be secondary to the above-stated larger issues.

Concretely, I'm saying thus:

+ bsdinstall lacks debugging (debugging is different than logging; from what I 
could see BSDINSTALL_LOG -- although utilized by both the sh(1) side and the C 
side -- is only populated during an installation). The ability to have the type 
of debugging that is in bsdconfig would greatly diminish the amount of time 
developing important new features.

+ pc-sysinstall lacks debugging (similar situation… producing a log for some 
action is not the same as being able to have debug statements for the purpose 
of enhancement the program or troubleshooting an enhancement)

+ bsdinstall separates the backend functionality and the front-end 
functionality into two separate namespaces (and in the case of C binaries, a 
third namespace)

+ pc-sysinstall separates one backend into more than one namespace

===

To get an idea of the type of debugging I'm talking about, install 
sysutils/bsdconfig from the ports tree or install it from a HEAD checkout of 
base (it's in usr.sbin) and execute:

bsdconfig -d
# produce debugging statements on stdout collated in realtime with the dialog 
screens

or

bsdconfig -D fooLogfile
# produce debugging statements in "fooLogfile" (debugging statements are hidden 
from stdout)

or

bsdconfig -D +fooLogfile
# produce debugging statements in both "fooLogfile" *and* on stdout (this is 
the same as "-dD fooLogfile")


As this stuff gets more modular and there are back-ends, front

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 26, 2013, at 12:37 PM, Teske, Devin wrote:

> 
> On May 26, 2013, at 11:14 AM, Bruce Cran wrote:
> 
>> On 26/05/2013 18:54, Teske, Devin wrote:
>>> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/harshbhatt/1
>> 
>> "This proposal is not made public, and you are not the student who submitted 
>> the proposal, nor are you a mentor for the organization it was submitted to."
>> 
> 
> So, uh… register?
> 
> I can see all private projects and all I did was register with google-melange.
> 
> I'm not aware of a way to make it public versus private.

The project was not slotted. :(
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 27, 2013, at 11:03 AM, Alfred Perlstein wrote:

> On 5/27/13 9:56 AM, Bruce Cran wrote:
>> On 27/05/2013 16:48, Alfred Perlstein wrote:
>>> Why can we not use in the interim use pc-sysinstall on the platforms that 
>>> it performs best on and use bsdinstall on the others?
>> 
>> Because pc-sysinstall doesn't have a UI - it's only a backend. If we update 
>> bsdinstall to use it, then it won't work on other platforms.
>> 
> This still doesn't make sense to me.  Why can bsdinstall not conditionally 
> use it?
> 

Because, believe it or not, not all programs are split in twain, having a 
front-end and a back-end.

I'm not defending it, and I'm not promoting it, but bsdinstall does things in a 
different way where
pc-sysinstall wants to be just a back-end. bsdinstall would have to go through 
a major revision
to make it use any external back-end. Currently it's one self-enclosed entity.


> Do we always have to seek the lowest common denominator for our user 
> experience?
> 

When the situation*is* that the release engineers can only embrace one 
installer for the release
media of more than just x86 architecture, the answer is… yes (common 
denominator required).

My thoughts are… let me toil on a new installer and then we can think about 
opening the can
of worms that is "how to enable conditional installers."

HINT: I already solved that problem… by modifying the boot loader Forth menu to 
allow the
creation of custom boot menus. Now all we need is another installer to elicit 
the use of that code
to present the choice the user. However… (and this is a big however), unless 
the 2nd choice
installer is as half-as-bad as bsdinstall… I don't see why it wouldn't just 
replace it (therefore
negating the need to invoke that code I put in to allow multiple choice 
installers at beastie menu).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 26, 2013, at 4:27 PM, Dirk Engling wrote:

> On 26.05.13 05:42, Teske, Devin wrote:
> 
>> I chose 100% sh for bsdconfig because of a few good reasons…
> 
> First, the partedit tool makes heavy use of libgeom and the structs
> returned from that lib, so I've rather wondered why for some parts C was
> preferred, and not the other way around.
> 

I tend to be of the mind that shell (gpart in this case) would be a better
choice for the installer than tapping into geom… (for the following)

Using gpart makes you exercise both the end-user utilities and the
developer framework (by-way of those utilities) whereas if you stick
to just the developer framework (libgeom in this case) there's a chance
that the installer can do things that can't be done from the command-line.

Just a thought.

If structs are what you want, I have those in bsdconfig:

dte...@scribe9.vicor.com share $ pwd
/home/dteske/src/freebsd_svn/base/head/usr.sbin/bsdconfig/share
dte...@scribe9.vicor.com share $ grep '^# f_' struct.subr 
# f_struct_define $type $member_name1 ...
# f_struct_new $type $name
# f_struct $name
# f_struct $name get $property [$var_to_set]
# f_struct $name set $property $new_value
# f_struct $name unset $property
# f_struct_free $name
# f_struct_copy $from_name $to_name

Naturally, because it's shell, the struct members are loosely typed (so
no need to define their type).

So I think there's great potential to write a very clean "gpart.subr" that
combines the power of the above "struct.subr" with perhaps another
of my modules…

dte...@scribe9.vicor.com share $ grep '^# f_' device.subr 
# f_device_try $name [$i [$var_path]]
# f_device_register $name $desc $devname $type $enabled $init_function \
# f_device_reset
# f_device_get_all
# f_device_name_get $type $name type|desc|max [$var_to_set]
# f_device_name_set $type $name $desc [$max]
# f_device_desc $device_name $device_type [$var_to_set]
# f_device_rescan
# f_device_find $name [$type [$var_to_set]] 
# f_device_init $name
# f_device_get $name $file [$probe]
# f_device_shutdown $name
# f_device_menu $title $prompt $hline $device_type [$helpfile]

NOTE: device.subr already uses struct.subr. For example, $device_type
is actually a struct type, and when you call f_device_get_all() it creates a
series of structs named "device_{name}" (where {name} is something
like "da0") and the struct holds many properties for the device.

I don't think there's any reason why we have to write it in C if we can write
it in sh.



> Still, thanks for pointing all that out, but I rather wanted to look at
> the installer from another angle, as it is supposed to provide everyone
> from FreeBSD novices to experts with a comfortable way to do things the
> right way and yet be flexible enough to avoid abandoning the tool once
> the requirements differ.
> 

I don't see your angle as perpendicular to my own… but rather that I would
like to seek to define in concrete terms what that means.

Working backwards from your list…

Flexibility: I think using a conflated shell namespace (where the entire
installer is sh and is in-turn scriptable by sh) gives the most flexibility. 
Much
more than flexibility, I think this approach also lowers the barrier-to-entry 
for
integration and automation engineers. Open questions: was the fact that
sysinstall was all C with a few forks to external programs a barrier to system-
integration and system-automation engineers trying to automate the install-
and-configure process? Maybe. The BSD-P certification exam requires you
to script sysinstall in FreeBSD-8. If we go all-shell, this would become much
easier IMHO.

Novices to Experts: I'd like to strive to hit a full spectrum between those two
points. I recognize that these are not two discrete ends of a dichotomous
tree, but instead a journey that is traversed (assuming the novice stays with
FreeBSD after trying it out). There are no defined sets of travel along this
line either, some people skip being a novice when they come to FreeBSD
for the first time because they have experience with similar operating systems.
That's why I've taken to developing every aspect of the utility. I want to see
the installer and configurator helpful to all people from developers to grand-
mothers and everybody in-between (that's the modular part… if you don't
like the way something works… the sh(1) nature allows you to simply
override it with your own module).




> So I wonder if there has ever been a best practices document on how to
> "properly" set up zpools, when to advice the user against using zfs at
> all, whether it makes sense to use geli on the boot device, when it is
> better to have multiple zpools and only encrypt the data pool(s). Maybe
> the installer should be advocating concepts like manageBE, pre-setting
> noexec-flags o

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 26, 2013, at 11:14 AM, Bruce Cran wrote:

> On 26/05/2013 18:54, Teske, Devin wrote:
>> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/harshbhatt/1
> 
> "This proposal is not made public, and you are not the student who submitted 
> the proposal, nor are you a mentor for the organization it was submitted to."
> 

So, uh… register?

I can see all private projects and all I did was register with google-melange.

I'm not aware of a way to make it public versus private.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 26, 2013, at 9:58 AM, Super Bisquit wrote:

May I- and others- see the hyperlink to the project,
please?


Absolutely…

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/harshbhatt/1
--
Devin



On Sat, May 25, 2013 at 11:45 PM, Teske, Devin 
mailto:devin.te...@fisglobal.com>> wrote:

On May 25, 2013, at 7:51 PM, Super Bisquit wrote:

> Please don't turn this into an architecture dependent mess. PCBSD is i386 &
> AMD64 only.
>

There's a GSoC project (of which I'm potential mentor) to fix that.

However, you are entirely right… we can't in all seriousness even think about 
using pc-sysinstall until it is solid on all architectures as bsdinstall 
already is.

GSoC project is: "Making pc-sysinstall FreeBSD ready by porting it to multiple 
architectures"
--
Devin



>
> On Sat, May 25, 2013 at 9:01 PM, Dirk Engling 
> mailto:erdge...@erdgeist.org>> wrote:
>
>> On 26.05.13 01:07, Nathan Whitehorn wrote:
>>
>>> I'm not aware of any movement there (on either side of the table). I'd
>>> personally be very suspicious of an all-sh(1) future -- by far the
>>> cleanest parts of bsdinstall are in C -- and this is especially true for
>>> interacting with geom. That said, since I've lost nearly all of my free
>>> time and ability to work on bsdinstall, I won't get in the way of anyone
>>> else working on things
>>
>> As discussed at BSDCan, I'd be willing to participate in the development
>> and at least implement setting up zpools/zfs and geli/gbde providers. I
>> have done similar things in sh in my ezjail tools and think I can glue
>> the rest together.
>>
>> Scanning through the pc-sysinstall code, I find nothing too fancy there
>> regarding either interaction with zfs nor geom tools. I do not think it
>> is necessary as a back end just for these features.
>>
>> Nathan, is there any design rationale available for the scripts, e.g. on
>> why you chose sh versus C and were you provided with some kind of wish
>> list/requirements in the first place? Any particular mail thread to scan
>> through beforehand?
>>
>> Regards,
>>
>>  erdgeist
>> ___
>> freebsd-hackers@freebsd.org<mailto:freebsd-hackers@freebsd.org> mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers<https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/mailman/listinfo/freebsd-hackers&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=PXUSUwGuSJd2O0fuIoJYV9V4EhVmQB9ADx3bEtQaxj4%3D%0A&s=a99d68ce305ffbaf9eb7021bfc9affbf5420722ada8561c144b10f9de922ff5d>
>> To unsubscribe, send any mail to 
>> "freebsd-hackers-unsubscr...@freebsd.org<mailto:freebsd-hackers-unsubscr...@freebsd.org>"
>>
> ___
> freebsd-hackers@freebsd.org<mailto:freebsd-hackers@freebsd.org> mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers<https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/mailman/listinfo/freebsd-hackers&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=PXUSUwGuSJd2O0fuIoJYV9V4EhVmQB9ADx3bEtQaxj4%3D%0A&s=a99d68ce305ffbaf9eb7021bfc9affbf5420722ada8561c144b10f9de922ff5d>
> To unsubscribe, send any mail to 
> "freebsd-hackers-unsubscr...@freebsd.org<mailto:freebsd-hackers-unsubscr...@freebsd.org>"

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 25, 2013, at 7:51 PM, Super Bisquit wrote:

> Please don't turn this into an architecture dependent mess. PCBSD is i386 &
> AMD64 only.
> 

There's a GSoC project (of which I'm potential mentor) to fix that.

However, you are entirely right… we can't in all seriousness even think about 
using pc-sysinstall until it is solid on all architectures as bsdinstall 
already is.

GSoC project is: "Making pc-sysinstall FreeBSD ready by porting it to multiple 
architectures"
-- 
Devin



> 
> On Sat, May 25, 2013 at 9:01 PM, Dirk Engling  wrote:
> 
>> On 26.05.13 01:07, Nathan Whitehorn wrote:
>> 
>>> I'm not aware of any movement there (on either side of the table). I'd
>>> personally be very suspicious of an all-sh(1) future -- by far the
>>> cleanest parts of bsdinstall are in C -- and this is especially true for
>>> interacting with geom. That said, since I've lost nearly all of my free
>>> time and ability to work on bsdinstall, I won't get in the way of anyone
>>> else working on things
>> 
>> As discussed at BSDCan, I'd be willing to participate in the development
>> and at least implement setting up zpools/zfs and geli/gbde providers. I
>> have done similar things in sh in my ezjail tools and think I can glue
>> the rest together.
>> 
>> Scanning through the pc-sysinstall code, I find nothing too fancy there
>> regarding either interaction with zfs nor geom tools. I do not think it
>> is necessary as a back end just for these features.
>> 
>> Nathan, is there any design rationale available for the scripts, e.g. on
>> why you chose sh versus C and were you provided with some kind of wish
>> list/requirements in the first place? Any particular mail thread to scan
>> through beforehand?
>> 
>> Regards,
>> 
>>  erdgeist
>> ___
>> freebsd-hackers@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>> 
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 25, 2013, at 6:01 PM, Dirk Engling wrote:

> On 26.05.13 01:07, Nathan Whitehorn wrote:
> 
>> I'm not aware of any movement there (on either side of the table). I'd
>> personally be very suspicious of an all-sh(1) future -- by far the
>> cleanest parts of bsdinstall are in C -- and this is especially true for
>> interacting with geom. That said, since I've lost nearly all of my free
>> time and ability to work on bsdinstall, I won't get in the way of anyone
>> else working on things
> 
> As discussed at BSDCan, I'd be willing to participate in the development
> and at least implement setting up zpools/zfs and geli/gbde providers. I
> have done similar things in sh in my ezjail tools and think I can glue
> the rest together.
> 

Very Cool!

I do encourage you to take a peak at bsdconfig either from HEAD or from ports 
(in sysutils)…

However, I'm getting ready to drastically change the API very soon (as 
previously threatened). I'm in the home-stretch and I'm trying to get in all 
the API changes before broaching the idea of taking off the "WITH_BSDCONFIG" 
build-option requirement.


> Scanning through the pc-sysinstall code, I find nothing too fancy there
> regarding either interaction with zfs nor geom tools. I do not think it
> is necessary as a back end just for these features.
> 

I tend to agree.

In fact… the directory structure of pc-sysinstall and even the way it stores 
the subroutines in *.sh files means I would be compelled to restructure the 
thing into proper "includes".

Since I intend to rework bsdinstall to use bsdconfig's libraries (e.g. 
"dialog.subr"), it sounds like a really nice path would be to develop:

base/head/usr.sbin/bsdconfig/share/zfs.subr
base/head/usr.sbin/bsdconfig/share/geom/
base/head/usr.sbin/bsdconfig/share/geom/geli.subr

And then bsdinstall could include those. The reason I tell myself that it would 
be better if they lived in bsdconfig and got imported at runtime by bsdinstall 
(rather than living in bsdinstall) is that I want to move to brand the 
utilities in this way:

bsdinstall is the program designed to install things (bare metal, jails, etc.)
bsdconfig is the program designed to configure things either during 
installation time or post-installation time

bsdinstall would be used on the boot media to install bare metal (but during 
that installation, made use bsdconfig for things like configuring users, boot 
services, networking, etc.). It will also be used after installation and 
running in multi-user land to do things like install jails.

So in other words… anytime something could conceivably be wanted by bsdconfig… 
we should just birth it there and have bsdinstall reach out for it. Seems to 
make sense… a person installs once but configures many times.

Guess I'm saying of course, that there'd be a great use for a zfs and geli 
library to bsdconfig for managing zfs after booting, etc.



> Nathan, is there any design rationale available for the scripts, e.g. on
> why you chose sh versus C and were you provided with some kind of wish
> list/requirements in the first place? Any particular mail thread to scan
> through beforehand?
> 

Can't answer for Nathan (and not sure if you want my opinion), but…

I chose 100% sh for bsdconfig because of a few good reasons…

I ultimately wanted to (and did) make it scriptable. The scripts are actually 
`sourced' shell scripts. So…

Because bsdconfig is sh, and the script is sh, the script has access to all of 
the bsdconfig internals, every API call, every variable, and can do nearly 
anything. There are no frustrating moments where a C aspect doesn't support 
running in a desired mode because that particular aspect was not made 
configurable or tunable. Not that this was (or is) a problem at all currently… 
just that it *was* a problem with sysinstall. For example…

sysinstall had a deviceRescan() function but the dispatch.c system did not make 
*that* particular function available through the system of hard-coded resWords 
(reserved words) that were allowed in a script. So… if you wanted to have a 
sysinstall script that (a) formatted some disks with some slices and (b) then 
formatted those slices with some BSD labels … well… you couldn't (note: this is 
not to say couldn't get sysinstall to write both slices and labels, just that 
if you wanted to do this *OUT* of the context of a full install, you couldn't). 
The problem was that you really needed to call "deviceRescan" after doing the 
slice action on the bare metal so that sysinstall would pick up the "s1" slice 
on which you wanted to later write labels on.

In the case of sysinstall… a one-line change of adding the deviceRescan() 
function to the resWord mapping in dispatch.c would have made that 
functionality available to scripts.

bsdconfig doesn't have that problem because the scripts are actually shell 
scripts and the old sysinstall commands are replicated by shell functions. 
There is never any need to "map" a function before it becomes available

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 25, 2013, at 4:07 PM, Nathan Whitehorn wrote:

> On 05/25/13 13:26, Bruce Cran wrote:
>> On 25/05/2013 17:15, Matt Olander wrote:
>>> From my vague recollection, we discussed improving bsdinstall by tying
>>> it in with pc-sysinstall, which we've been threatening to do for at
>>> least a year. Also, there was much discussion about Devin's bsdconfig
>>> perhaps tying in with a Google SoC Project.
>>> 
>>> I think Devin was nominated for most of the work, since he was unable
>>> to defend himself :P
>> 
>> Thanks. From previous discussions with Devin I think he has other plans for 
>> the installer that don't involve pc-sysinstall. But since it seems the 
>> future is all sh(1) code, I won't be able to contribute.
>> 
>> https://wiki.freebsd.org/PCBSDInstallMerge lists a few limitations with 
>> pc-sysinstall - are these being fixed?
>> 
> 
> I'm not aware of any movement there (on either side of the table). I'd 
> personally be very suspicious of an all-sh(1) future -- by far the cleanest 
> parts of bsdinstall are in C -- and this is especially true for interacting 
> with geom.

So that I can get a feel for the expectations on quality of product…

You say the cleanest parts of bsdinstall are in C.

What makes the sh parts unclean? Not looking for any particular answer… just 
want your opinion.

I've been working very hard to produce a heavy-lifting "dialog.subr" (see 
base/head/usr.sbin/bsdconfig/share/dialog.subr) which makes dialog(1) work very 
nice and clean in sh(1). However, this may not be your concern, and you may 
instead have some other "cleanliness" insight that I can address in my work.
-- 
Devin


> That said, since I've lost nearly all of my free time and ability to work on 
> bsdinstall, I won't get in the way of anyone else working on things
> -Nathan
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 25, 2013, at 11:26 AM, Bruce Cran wrote:

> On 25/05/2013 17:15, Matt Olander wrote:
>> From my vague recollection, we discussed improving bsdinstall by tying
>> it in with pc-sysinstall, which we've been threatening to do for at
>> least a year. Also, there was much discussion about Devin's bsdconfig
>> perhaps tying in with a Google SoC Project.
>> 
>> I think Devin was nominated for most of the work, since he was unable
>> to defend himself :P
> 
> Thanks. From previous discussions with Devin I think he has other plans for 
> the installer that don't involve pc-sysinstall. But since it seems the future 
> is all sh(1) code, I won't be able to contribute.
> 

The future of how these softwares become entangled to produce something better:

+ bsdinstall
+ pc-sysinstall
+ bsdconfig

Is in my mind entirely still open as I work to finish up bsdconfig.

I was thinking…

Perhaps just rewrite bsdinstall from scratch (using the existing code as a 
template).

Have to put pc-sysinstall on the back-burner for any/all considerations until 
the code is cleaned up and actually usable on all architectures (there's a GSoC 
project to do exactly that -- I'm the potential mentor; project is pending 
status).

So unless this GSoC goes through and we are able to (as we plan) clean up that 
mess…

Defacto plan is to just rewrite bsdinstall from scratch (again… using the 
existing code as a template).

In said rewrite… I'd *heavily* leverate usr.sbin/bsdconfig/share/*.subr 
(specifically "dialog.subr" -- the abstraction layer that allows me to have 
nice i18n-ready dialogs and also gracefully handle dialog in a way that makes 
my code look very clean).



> https://wiki.freebsd.org/PCBSDInstallMerge lists a few limitations with 
> pc-sysinstall - are these being fixed?
> 

I can see if the GSoC student for the "Making pc-sysinstall FreeBSD ready by 
porting it to multiple architectures" project is willing to incorporate any of 
those limitations into his work. But I think the focus of the project should be 
to clean up the code and make it work on at least one other important non-x86 
architecture. Barring that…

You're absolutely right in stating that any/all discussions on merging 
pc-sysinstall with bsdinstall would result in a regression with pc-sysinstall 
in its current state.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD installers and future direction

[Teske, Devin]

On May 25, 2013, at 9:15 AM, Matt Olander wrote:

> On Sat, May 25, 2013 at 8:43 AM, Bruce Cran  wrote:
>> 
>> I heard there was some discussion at BSDCan about the direction of a future 
>> FreeBSD installer.  Considering we currently have bsdinstall, pc-sysinstall, 
>> and an effort to revive sysinstall, I'd be interested to know what was 
>> decided (if anything) and whether I could help make progress towards getting 
>> a single really good installer/frontend - instead of the current situation 
>> with several, none of which have a much-needed UI for setting up an 
>> installation on ZFS.
> 
> Hey Bruce,
> 
> From my vague recollection, we discussed improving bsdinstall by tying
> it in with pc-sysinstall, which we've been threatening to do for at
> least a year. Also, there was much discussion about Devin's bsdconfig
> perhaps tying in with a Google SoC Project.
> 

There is indeed a GSoC project to address the situation w/regard to installers.

The GSoC project is one submitted by Harsh Bhatt and I've submitted that I wish 
to Mentor. The project is titled:

"Making pc-sysinstall FreeBSD ready by porting it to multiple architectures"

The project is designed as such to increase possibilities w/respect to 
installers. To elaborate…

Integrating bsdinstall with pc-sysinstall would introduce a regression because 
bsdinstall currently supports all platforms, whereas pc-sysinstall has 
hard-coded assumptions specific to the x86 platform (i386 and amd64 included). 
If bsdinstall was ever going to be programmed to use pc-sysinstall as a 
back-end, pc-sysinstall would have to be cleaned up.

I'm in no way pushing to integrate bsdinstall with pc-sysinstall… but I *am* 
saying this is a GSoC project to look out for. The goal of the project is to 
see if it is even possible to remedy any possibility that tying bsdinstall to 
pc-sysinstall would introduce a regression in platform support. If the project 
is successful, PC-BSD should be able to immediately benefit from the fruits 
thereof (as -- correct me if I'm wrong -- the graphical PC-BSD installer uses 
pc-sysinstall as a back-end).

ASIDE: For what it's worth, it's somewhat convenient to think that in a simple 
world -- because pc-sysinstall is already the backend of the PC-BSD GUI 
installer -- FreeBSD would have bsdinstall as the TUI front-end to the same 
back-end. But however, I'm not naïve and can't imagine that as being clean or 
elegant unless we can clean up pc-sysinstall. Cleaning up the code is a another 
major focal-point of the aforementioned GSoC project.

With respect to my bsdconfig… (how it relates to installers)

Just as there were blockers preventing pc-sysinstall from being integrated into 
bsdinstall.

There are blockers that prevent bsdinstall from being integrated into the 
larger bsdconfig framework.

In the case of pc-sysinstall integrating to bsdinstall, pc-sysinstall doesn't 
support all the target architectures that bsdinstall does. Meanwhile, in the 
case of bsdinstall integrating into bsdconfig, bsdinstall doesn't support all 
the features of bsdconfig.

Luckily, introduction of most features to bring bsdinstall on-par with 
bsdconfig will be easy as we can just make bsdinstall use the subroutine 
includes from bsdconfig. However, there are other things that just can't be 
done without plain sweat and labor…

For example, making bsdinstall i18n-ready (as bsdconfig is). I expect this to 
take (with a medium effort) a week or two, aided by the fact that the dialog(1) 
abstraction API offered by bsdconfig makes most of that transparent (for 
example, you don't have to worry about whether the "Yes" button says "Ja", 
"Oui", or "Yes" -- you just call f_dialog_yesno() and it worried about how to 
call dialog(1) to form the proper i18n-compatible prompt).

Another big change to bsdinstall would be to make it *more* modular and rewrite 
the C components to be in sh.


> I think Devin was nominated for most of the work, since he was unable
> to defend himself :P
> 

I don't mind being volunteered. In earnest, I figure the code I'm working on is 
volunteering enough.
-- 
Devin




_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

[UPDATE] sysutils/bsdconfig snapshot

[Teske, Devin]

Hi fellow -hackers@,

I've taken a new snapshot of HEAD usr.sbin/bsdconfig and made it available 
through the ports tree. The last snapshot was almost 12 full months ago, and a 
lot has changed since then.

Most notably, we have the beginnings of the package management module now and 
we're edging ever-closer to 1.0 release status.

I'd like to see if there are any interested folks out there that could give my 
updated sysutils/bsdconfig port a go and provide some feedback (while I'm still 
in lighter development phase).

Any/all feedback would be greatly appreciated.

Just an FYI however… this code is only expected to work on 9.0-R or higher.
-- 
Cheers,
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: GSoC: PKGNG GUI Proposal Available for Review

[Teske, Devin]

On May 3, 2013, at 1:33 AM, Wojciech Puchar wrote:

good for today and future ladmins that cannot type a command.

Any USEFUL proposals that add some real functionality?


WIth great respect, I disagree with the dismissal that a GUI itself cannot 
bring value that a command-line tool couldn't otherwise bring to the table.

For example, in a stateful modal dialog, I believe that part of the value-add 
is seeing realtime calculations being performed based on user input. For a 
concrete example, imagine as you are checking/unchecking boxes of what to 
install, if the GUI continually keeps up-to-date a display of selected 
dependencies (packages and leaves), then that is something that on the 
command-line tool is more difficult.

What is the value-add in that you may say? Exploring, of course! Imagine that 
you have a need to fill, you go into a particular package category, and are 
faced with 5 things that all fill the same basic need -- but perhaps all but 
one has a massive runtime dependency list, so you choose that one. In this 
example, the GUI is far superior to command-line tools.

I'm actually taking the same approach in the design of "bsdconfig packages" 
(visible here: http://twitpic.com/ci2rid ) in that the TUI based management 
will aim to give you all that extra value-added information that would 
otherwise take multiple command-line queries and extra effort to correlate.

I argue that the goal should not be to develop tools that are useful for (as 
you call them) "ladmins" … but develop tools that the developers themselves 
find useful.

I personally feel that I myself have failed as a developer if I ever develop a 
tool that I don't use myself (or at least find useful in replacing an old way 
of doing something that is much more difficult).
--
Devin

P.S. I'm sorry… but that callous remark sparked a fire in me. Had to set the 
record straight… we need to give this student a running chance -- don't dare 
say this won't be useful (I've read the project proposal… it's good and it has 
bapt's +1 iirc, so that makes it good as gold basically)



On Fri, 3 May 2013, Justin Edward Muniz wrote:

Thank you everyone for helping me create a suitable project to propose. I
have submitted a draft of my proposal, though I am still in the process of
enhancing it. If anyone has the time, please check it out and I'll gladly
accept any feedback.

I am new to Google Summer of Code, and just discovered I could update my
proposal after submitting it. Initially I uploaded most of the proposal but
I am still finishing the last parts. Any advice could help me (or others)
develop future proposals, so I hope to hear from people even after the
deadline.

My proposal can be read at the following address:
https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/justin_muniz/1

I appreciate you taking the time to read this email. Happy coding everyone.

Justin Muniz
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to 
"freebsd-hackers-unsubscr...@freebsd.org"


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: GSOC: Qt front-ends

[Teske, Devin]

On Apr 24, 2013, at 2:33 PM, Fernando Apesteguía wrote:


El 24/04/2013 21:18, "Teske, Devin" 
mailto:devin.te...@fisglobal.com>> escribió:
>
>
> On Apr 24, 2013, at 11:54 AM, Baptiste Daroussin wrote:
>
> > On Wed, Apr 24, 2013 at 02:03:56PM -0400, Justin Edward Muniz wrote:
> >>>
> >>> I think the interface to pkgng and freebsd-update are still
> >>> interesting; at least more worthwhile than the kernel configuration
> >>> one.
> >>>
> >>> I think the pkgng one has the edge, since packages are updated far
> >>> more often than base, and it's easier to track base.
> >>>
> >>> Now you are at a stage where you should make your own decision; which
> >>> one looks the most interesting to you?  Once you decide on an area of
> >>> interest, you can just start hacking :)
> >>>
> >>> Chris
> >>>
> >>
> >>
> >> That's good to hear.
> >>
> >> I am sure that you are right, a pkgng GUI would probably see more use in
> >> general. I am definitely close to making my decision, but this thread has
> >> been so much help, I am glad for the insight.
> >>
> >> The coding is what I look forward to the most :D
> >
> > imho a pkgng frontend should be done via packagekit, just write a pkgng 
> > backend
> > for packagekit and you will gain for FreeBSD a KDE frontend and a GTK 
> > frontend.
> >
> > That said any frontend at convenience to contributor will be anyway good :)
> >
>
> If you could pardon my ignorance… but what is packagekit again (for the 
> benefit of others)?

It's an application to manage packages. It is developed in a way that it's easy 
to add new backends keeping the same interface. See[1] for the general 
information and this[2] page for the currently supported back ends.

[1] 
http://www.packagekit.org<https://urldefense.proofpoint.com/v1/url?u=http://www.packagekit.org&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=8MiGlyOMD3O%2FR2YU9sNxl1vMPdajxy%2FqKps59tnvAWw%3D%0A&s=29faa229ba8cb89cdb69d00087e23dde5669cdb61308c5b6d44156beb6d8766e>

[2] 
http://www.packagekit.org/pk-matrix.html<https://urldefense.proofpoint.com/v1/url?u=http://www.packagekit.org/pk-matrix.html&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=8MiGlyOMD3O%2FR2YU9sNxl1vMPdajxy%2FqKps59tnvAWw%3D%0A&s=a802599114b383f22d717ee7fc4e7fc54e911e80958ed8f20c9a31228a3dbea5>


Cool. Kinda reminds me of "SANE" for interfacing with scanners.
--
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: GSOC: Qt front-ends

[Teske, Devin]

On Apr 24, 2013, at 11:54 AM, Baptiste Daroussin wrote:

> On Wed, Apr 24, 2013 at 02:03:56PM -0400, Justin Edward Muniz wrote:
>>> 
>>> I think the interface to pkgng and freebsd-update are still
>>> interesting; at least more worthwhile than the kernel configuration
>>> one.
>>> 
>>> I think the pkgng one has the edge, since packages are updated far
>>> more often than base, and it's easier to track base.
>>> 
>>> Now you are at a stage where you should make your own decision; which
>>> one looks the most interesting to you?  Once you decide on an area of
>>> interest, you can just start hacking :)
>>> 
>>> Chris
>>> 
>> 
>> 
>> That's good to hear.
>> 
>> I am sure that you are right, a pkgng GUI would probably see more use in
>> general. I am definitely close to making my decision, but this thread has
>> been so much help, I am glad for the insight.
>> 
>> The coding is what I look forward to the most :D
> 
> imho a pkgng frontend should be done via packagekit, just write a pkgng 
> backend
> for packagekit and you will gain for FreeBSD a KDE frontend and a GTK 
> frontend.
> 
> That said any frontend at convenience to contributor will be anyway good :)
> 

If you could pardon my ignorance… but what is packagekit again (for the benefit 
of others)?
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: GSOC: Qt front-ends

[Teske, Devin]

On Apr 24, 2013, at 11:51 AM, Teske, Devin wrote:


On Apr 24, 2013, at 11:10 AM, Freddie Cash wrote:

On Wed, Apr 24, 2013 at 11:03 AM, Justin Edward Muniz <
justin.mu...@maine.edu<mailto:justin.mu...@maine.edu>> wrote:


I think the interface to pkgng and freebsd-update are still
interesting; at least more worthwhile than the kernel configuration
one.

I think the pkgng one has the edge, since packages are updated far
more often than base, and it's easier to track base.

Now you are at a stage where you should make your own decision; which
one looks the most interesting to you?  Once you decide on an area of
interest, you can just start hacking :)

Chris



That's good to hear.

I am sure that you are right, a pkgng GUI would probably see more use in
general. I am definitely close to making my decision, but this thread has
been so much help, I am glad for the insight.

The coding is what I look forward to the most :D


You'll probably want to get in touch with the PC-BSD folks.  As they are
moving to pkgng for everything, they are updating their Python-based GUIs
to work with it.  Might be a possibility to work together, or to build off
what they have, or to get ideas/inspiration for a more general tool.

For example, (going from memory of my home PC-BSD install) the System
Update or System Manager tool uses pkgng behind the scenes, and provides a
tree-based view of PC-BSD-specific packages that can be installed via
simply ticking checkboxes and hitting Install button.

And, they have a ports-based GUI tool as well, although I have not used it
as yet so couldn't tell you what it supports.  I do my ports-based installs
via a terminal.  :)


I've been planning a pkgng management tool in base for a while now (and am 
closing in on that goal).

The tool is bsdconfig

It's relevant to this discussion because it supports running both in GUI and in 
TUI.

This is accomplished by using dialog(1) for TUI and Xdialog(1) (from ports) for 
GUI. One code base, two modes.

The package management is being implemented as a bsdconfig(8) module in HEAD 
(see usr.sbin/bsdconfig).


Clarification:

The module is being *implemented* in HEAD, but is being *developed* on 
SF.net<http://SF.net> (URL Below):

http://druidbsd.sf.net/download/bsdconfig/

Right now, if you download the latest tarball from that directory 
(bsdconfig.YYMMDD-#.tgz) and replace "usr.sbin/bsdconfig" in your checked-out 
tree, you'll have ~1500 lines more than HEAD (at the time of this writing).

My plan is to (before the next BAFUG) commit the packages module in one swift 
action (hence why I'm developing it outside of the main tree).
--
Devin



Executing "bsdconfig packages" produces something inspired by sysinstall but 
greatly improved (faster, cleaner, more efficient, and provides more data).

Here's a screenshot:
http://twitpic.com/ci2rid

Sorry, no screenshot of the X11 side yet.

Executing "bsdconfig -X packages" or "bsdconfig packages -X" gives you the X11 
GUI.

Is it the flashiest GUI you've ever seen? Far from it. But when I've demo'd the 
code, people have been generally positive about the approach.

Just wanted to let you know what my plans are.

Feel free to go full-boar with a Qt-based front-end, just wanted to let you 
know what I'm cooking in HEAD.
--
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: GSOC: Qt front-ends

[Teske, Devin]

On Apr 24, 2013, at 11:10 AM, Freddie Cash wrote:

On Wed, Apr 24, 2013 at 11:03 AM, Justin Edward Muniz <
justin.mu...@maine.edu> wrote:


I think the interface to pkgng and freebsd-update are still
interesting; at least more worthwhile than the kernel configuration
one.

I think the pkgng one has the edge, since packages are updated far
more often than base, and it's easier to track base.

Now you are at a stage where you should make your own decision; which
one looks the most interesting to you?  Once you decide on an area of
interest, you can just start hacking :)

Chris



That's good to hear.

I am sure that you are right, a pkgng GUI would probably see more use in
general. I am definitely close to making my decision, but this thread has
been so much help, I am glad for the insight.

The coding is what I look forward to the most :D


You'll probably want to get in touch with the PC-BSD folks.  As they are
moving to pkgng for everything, they are updating their Python-based GUIs
to work with it.  Might be a possibility to work together, or to build off
what they have, or to get ideas/inspiration for a more general tool.

For example, (going from memory of my home PC-BSD install) the System
Update or System Manager tool uses pkgng behind the scenes, and provides a
tree-based view of PC-BSD-specific packages that can be installed via
simply ticking checkboxes and hitting Install button.

And, they have a ports-based GUI tool as well, although I have not used it
as yet so couldn't tell you what it supports.  I do my ports-based installs
via a terminal.  :)


I've been planning a pkgng management tool in base for a while now (and am 
closing in on that goal).

The tool is bsdconfig

It's relevant to this discussion because it supports running both in GUI and in 
TUI.

This is accomplished by using dialog(1) for TUI and Xdialog(1) (from ports) for 
GUI. One code base, two modes.

The package management is being implemented as a bsdconfig(8) module in HEAD 
(see usr.sbin/bsdconfig).

Executing "bsdconfig packages" produces something inspired by sysinstall but 
greatly improved (faster, cleaner, more efficient, and provides more data).

Here's a screenshot:
http://twitpic.com/ci2rid

Sorry, no screenshot of the X11 side yet.

Executing "bsdconfig -X packages" or "bsdconfig packages -X" gives you the X11 
GUI.

Is it the flashiest GUI you've ever seen? Far from it. But when I've demo'd the 
code, people have been generally positive about the approach.

Just wanted to let you know what my plans are.

Feel free to go full-boar with a Qt-based front-end, just wanted to let you 
know what I'm cooking in HEAD.
--
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Rebooting from loader causes a "fault" in VMware Workstation

[Teske, Devin]

+1 you rock.

I was silently watching this thread from the start, thinking…

Oh gawd, please don't let this be associated with the massive Forth changes 
I've rolled in (this much I had doubted heavily, but kept a watchful eye just 
in-case).
-- 
Devin


On Apr 23, 2013, at 4:11 PM, Adrian Chadd wrote:

> Hah, nice catch! You guys rock.
> 
> Scratch one less weird shit thing with FreeBSD on VMWARE.
> 
> 
> 
> Adrian
> 
> On 23 April 2013 16:03, Dimitry Andric  wrote:
>> 
>> On Apr 24, 2013, at 00:03, Dimitry Andric  wrote:
>> 
>>> On Apr 23, 2013, at 23:46, Andriy Gapon  wrote:
 on 23/04/2013 19:31 John Baldwin said the following:
> On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
>>> ...
>> 0x90e8:  lgdtl  0x95d0
>> 0x90ef:  ljmpw  $0x18,$0x90f5
>> 
>> Triple fault
>> CPU Reset (CPU 0)
>> ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=1800
>> EIP=90ef EFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>> ES =0033 a000  00cff300 DPL=3 DS   [-WA]
>> CS =0008   00cf9a00 DPL=0 CS32 [-R-]
>> SS =0010   00cf9300 DPL=0 DS   [-WA]
>> DS =0033 a000  00cff300 DPL=3 DS   [-WA]
>> FS =0033 a000  00cff300 DPL=3 DS   [-WA]
>> GS =0033 a000  00cff300 DPL=3 DS   [-WA]
>> LDT=   8200 DPL=0 LDT
>> TR =0038 5f98 2067 8900 DPL=0 TSS32-avl
>> GDT= ff85c789 
> 
> This seems wrong (address is way too high).  I wonder if the gdtdesc was
> trashed by something?  Can you dump memory before the lgdtl instruction 
> at the
> 0x95d0 address?
 
 Looks correct:
 Breakpoint 1, 0x90e8 in ?? ()
 (gdb) x/i $eip
 0x90e8: lgdtl  0x95d0
 (gdb) x/3xh 0x95d0
 0x95d0: 0x003f  0x9590  0x
 (gdb) x/16xh 0x9590
 0x9590: 0x  0x  0x  0x  0x  0x  0x9a00  0x00cf
 0x95a0: 0x  0x  0x9300  0x00cf  0x  0x  0x9a00  0x
 
 Nevertheless doing stepi leads to exactly the same triple fault.
>>> 
>>> 
>>> Is it because lgdt loads the GDT from the ds segment, and ds is now 33,
>>> not 0 (or equal to CS, I'm not sure which is correct here)?
>> 
>> Indeed, the DS segment was incorrect, the GDT should be loaded from the
>> CS segment instead.  This diff fixes the issue for me (and now "reboot"
>> command from loader nicely reboots in VMware):
>> 
>> Index: sys/boot/i386/btx/btx/btx.S
>> ===
>> --- sys/boot/i386/btx/btx/btx.S (revision 248910)
>> +++ sys/boot/i386/btx/btx/btx.S (working copy)
>> @@ -248,7 +248,7 @@ exit:   cli # 
>> Disable interrupts
>> /*
>>  * Restore the GDT in case we caught a kernel trap.
>>  */
>> -   lgdt gdtdesc# Set GDT
>> +   lgdt %cs:gdtdesc# Set GDT
>> /*
>>  * To 16 bits.
>>  */
>> 
>> ___
>> freebsd-hackers@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: rsh/rlogin strange behavior

[Teske, Devin]

On Thu, 14 Feb 2013, Wojciech Puchar wrote:

> it is FreeBSD 9, em or re or bge hardware but rlogin goes over tun(4)
> interface.
> 
> in the same time rcp works fine even for gigabyte file.
> 
> any more ideas?

Try to isolate the problem as network or disk or other...

systat -iostat 1
netstat 1
systat -vmstat 1

NOTE: Don't forget systat takes ":ignore " which can be handy at times 
if you have a lot of devices

Those are a good start. Others can offer others to see where your data is 
choking.

HINT: Look for errors in the "netstat 1" output?
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: rsh/rlogin strange behavior

[Teske, Devin]

On Thu, 14 Feb 2013, Wojciech Puchar wrote:

> i use rsh/rlogin regularly within LAN and over encrypted tunnels
> it works generally fine but have strange behavior
> 
> when i output long amount of text in console (eg. cat bigfile), where long
> is like 20kB it
> 
> a) display part of it and hangs (i have to kill rlogin) - rarely
> b) display part of it and rest is skipped. then i can work normally.
> 
> 
> ssh doesn't have such a problem.
> 
> what is wrong?
> 

This sounds oddly like a bug we discovered back in the 4 days with rsh.

We discovered a bug years ago when moving from FreeBSD-4.8 to 4.11 (with many 
back-ported drivers) that a combination of the em(4) driver (back-ported from 
RELENG_6) and changes to libc ended up in the traces.

We could easily replicate the issue in csh with:

repeat 100 rsh  date

HINT: Set yourself up in /etc/hosts.equiv on  for password-less entry

Repeat about 5 or 6 times and then eventually the connection will hang and you 
won't be able to make more connections for some time.

Next step? Execute "netstat -an | less" and look for oddities (like a mass pile 
of FIN_WAIT_2 connections).

In our case (ymmv) the final ACK was not being sent leaving the client side 
stacking up a bunch of connections that take msl.timeout time to expire (iirc). 
If I do remember correctly the problem happened when the server was using an 
em(4) driver.

Our ultimate solution was to either switch critical servers to fxp(4) based 
hardware or roll entire sites over to using key-based SSH (which may work for 
you -- have you thought about giving ssh-keygen a try? that is, if you're using 
rsh for the convenience of password-less entry via hosts.equiv for example).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: Xorg help

[Teske, Devin]

(first, apologies for the top-post; using a dumb web-mail client that can't 
handle inline)

Hi,

We use LG Flatron at $work (tho not wide-aspect like the model you mention -- 
read: we run our LG Flatron LCDs at 1600x1200). I've had a little experience in 
working on higher definitions tho (like 1920x1080).

Very first thing I do is I run "xrandr" with no arguments to see if the mode 
that I want is listed and available, just not used.

If the resolution you want is listed in the xrandr output, then switching to it 
is as simple as running "xrandr --size WxH" where W is pixel-width and H is 
pixel-height (e.g. "xrandr --size 1920x1080"). After which, you can make this 
mode your default by adding the following to  the appropriate "Display" 
subsection in /etc/X11/xorg.conf:

Modes "1920x1080"

However, if instead the desired mode is _not_ listed by xrandr, it could be as 
simple as switching cables (if you're trying to hit 1920x1080 for example, 
avoid [S]VGA and try DVI or HDMI or DP; switching cables could help).

Next, there's a possibility you're not using a driver that supports your 
graphics card. What I do in that situation is run (as root):

X -configure :99

Then I go look at the Driver settings in /root/xorg.conf.new -- if it comes 
back as "vesa" then that's the fallback driver and you can't make use of 
anything higher than 1600x1200. If it comes back as something other than "vesa" 
like "nvidia", "ati", "radeon", or "intel", then there's a chance you can hit 
1920x1080 but we're not done yet.

Last thing to do is to update xf86-video-* driver from the ports tree (pick the 
one most appropriate for your Desktop hardware).
-- 
Devin



From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] on 
behalf of Niclas Zeising [zeis...@freebsd.org]
Sent: Thursday, January 31, 2013 5:31 AM
To: Wojciech Puchar
Cc: hack...@freebsd.org; x...@freebsd.org
Subject: Re: Xorg help

This should have been sent to x11@ instead.
On 01/31/13 14:20, Wojciech Puchar wrote:
> long time ago  with CRT monitors i used xvidtune and defined my modeline
> based on existing one.
>
> With LCD laptop Xorg automatically selected good one.
>
> Now with desktop and new LG monitor capable of 1920x1080 it uses 1024x768
>
> no possible modelines are displayed and i have no idea how to set it
> properly.
>
> It is LG Flatron E2211 if it helps.
>
> What driver should i use with Atom D525? xf86-video-intel29 is the only
> one that works, in spite of market as not supported.
>
> Or am i missing something?

xf86-video-intel29 is not supported.  It was used for a short time when
gem/kms was still developed.  I have no idea what graphics card your
atom comes with, it has integrated graphics, but you have to find out
which exact version it is.  In general, for newer intel graphics cards,
the best is to use the new xorg distribution, that should give you
hardware acceleration.  Otherwise you can try xf86-video-intel in the
old xorg distribution, but the risk is that it will revert back to using
vesa instead.
Regards!
--
Niclas Zeising
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: /etc/resolv.conf getting over written with dhcp

[Teske, Devin]

On Jun 15, 2012, at 5:47 AM, Volodymyr Kostyrko  wrote:

> Varuna wrote:
>> Hello Folks,
>> 
>> Noticed a strange issue with the creation / update of /etc/resolv.conf.
>> The details of the system that I noticed the issue on is:
>> Version : FreeBSD 8.0
>> Patch level: not patched
>> Uname: FreeBSD shastry.eudaemonicsystems.net 8.0-RELEASE FreeBSD
>> 8.0-RELEASE #0: Thu Sep 29 22:37:51 IST 2011
>> r...@shastry.bhuta.in:/usr/obj/usr/src/sys/SHASTRY i386
>> 
>> 
>> I generally have a static IP 192.168.98.6 (via rc.conf) for my Beastie.
>> The contents of my /etc/resolv.conf is as follows:
>> domain eudaemonicsystems.net
>> nameserver 208.67.222.222
>> nameserver 208.67.220.220
>> nameserver 4.2.2.2
>> No matter how many times I reboot the system, the resolv.conf does not
>> get overwritten when configured with a static IP.
> 
> 1. Since 9.0 we already have resolveconf(8) for this.
> 2. Empty dhclient.conf means default configuration, you can make your own, 
> refusing nameserver updates coming from DHCP.
> 3. You can always chflags noschg any precious file.
> 

schg to disallow changes.

noschg is incorrect.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: detailed map of WIRED memory under FreeBSD 9

[Teske, Devin]

On Jun 1, 2012, at 1:19 AM, Wojciech Puchar  
wrote:

> what tool and how can be used to display detailed map what exactly wired 
> memory on my system as it is far way too much (1.5GB out of 4GB RAM).
> 

dmidecode?



-- 
Devin


> i do run 4 virtualboxes but one have 256MB RAM, the others 192 and when i 
> turn them off wired memory goes down right amount but still it is too much 
> used.
> 
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

FW: [RELEASE] New Boot-Loader Menu bugs?

[Teske, Devin]

-Original Message-
From: Devin Teske [mailto:dte...@vicor.com] 
Sent: Sunday, July 17, 2011 4:45 PM
To: 'Andrey Fesenko'; 'freebsd-hackers@freebsd.org'
Cc: Julian Elischer; Teske, Devin (devin.te...@fisglobal.com)
Subject: RE: [RELEASE] New Boot-Loader Menu bugs?

> -Original Message-
> From: Andrey Fesenko [mailto:f0and...@gmail.com]
> Sent: Sunday, July 17, 2011 12:33 AM
> To: freebsd-hackers@freebsd.org; dte...@vicor.com
> Subject: [RELEASE] New Boot-Loader Menu bugs?
> 
> Last Changed Rev: 224125

Are you sure that's the right rev? That rev (by dougb) appears to be related to 
default empty zones in `/etc/namedb/named.conf', and completely unrelated to my 
rev 222417 (which you appear to be referencing below).


> Not update share/examples/bootforth/* any files old version loader.
> 
> file sys/boot/forth/loader.conf
> ##
> ###  Loader settings  
> ##
> 
> not actual logo list
> #loader_logo="fbsdbw" # Desired logo: fbsdbw, beastiebw,
> beastie, none
> need
> #loader_logo="orbbw"  # Desired logo: orb, orbbw, fbsdbw, beastiebw,
> beastie, none
> 
> maybe over loader option.

It took me awhile, but I think I see what you're saying.

That the following patch needs to be applied to head/sys/boot/forth/loader.conf 
to be consistent with the changes that were made against 
head/sys/boot/forth/loader.conf.5 (in rev 222417):


--- loader.conf.origSun Jul 17 16:37:35 2011
+++ loader.conf Sun Jul 17 16:38:09 2011
@@ -47,7 +47,8 @@
# escape to the loader prompt, set to
# "NO" to disable autobooting
 #beastie_disable="NO"  # Turn the beastie boot menu on and off
-#loader_logo="fbsdbw"  # Desired logo: fbsdbw, beastiebw, beastie, none
+#loader_logo="orbbw"   # Desired logo: orb, orbbw, fbsdbw, beastiebw,
+   # beastie, none
 #comconsole_speed="9600"   # Set the current serial console speed
 #console="vidconsole"  # A comma separated list of console(s)
 #currdev="disk1s1a"# Set the current device


Does anybody object to the above patch?
-- 
Devin

_

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"