new dialog/libdialog testing
Having some time to test 9.0-CURRENT with the new dialog command has uncovered only one major omission (for us): prgbox/dialog_prgbox. This is used in most (if not all) of our installation/management scripts. Was prgbox omitted for any particular reason? I realize that change is inevitable. Is there a better approach to running a program in a window? We like many of the new features presented, but are wary of problems down the road due to the omission of prgrbox. I notice that sysinstall uses dialog_prgbox in 8.1-RELEASE. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: new dialog/libdialog testing
On Wed, Feb 9, 2011 at 7:28 AM, David Boyd wrote: > Having some time to test 9.0-CURRENT with the new dialog command has > uncovered only one major omission (for us): prgbox/dialog_prgbox. > > This is used in most (if not all) of our installation/management scripts. > > Was prgbox omitted for any particular reason? > > I realize that change is inevitable. > > Is there a better approach to running a program in a window? > > We like many of the new features presented, but are wary of problems down > the road due to the omission of prgrbox. > > I notice that sysinstall uses dialog_prgbox in 8.1-RELEASE. A good chunk of stuff isn't in the new libdialog. Part of the reason why is that libodialog is hacked from what it was originally by various parties and wasn't carried over to the [now supported] upstream maintainer, or because support for other APIs was deprecated and abandoned. That being said, other APIs should easily fill this gap in a more generic manner. You may have to specify a few more libdialog API calls to achieve the same result though. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: new dialog/libdialog testing
On 02/09/11 10:15, Garrett Cooper wrote: On Wed, Feb 9, 2011 at 7:28 AM, David Boyd wrote: Having some time to test 9.0-CURRENT with the new dialog command has uncovered only one major omission (for us): prgbox/dialog_prgbox. This is used in most (if not all) of our installation/management scripts. Was prgbox omitted for any particular reason? I realize that change is inevitable. Is there a better approach to running a program in a window? We like many of the new features presented, but are wary of problems down the road due to the omission of prgrbox. I notice that sysinstall uses dialog_prgbox in 8.1-RELEASE. A good chunk of stuff isn't in the new libdialog. Part of the reason why is that libodialog is hacked from what it was originally by various parties and wasn't carried over to the [now supported] upstream maintainer, or because support for other APIs was deprecated and abandoned. That being said, other APIs should easily fill this gap in a more generic manner. You may have to specify a few more libdialog API calls to achieve the same result though. Right (and apologies for breakage). You can get something similar and somewhat more flexible by piping the command into dialog --progressbox. You might also want to look at the tailbox command. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
pc-sysinstall and pxeboot
Has anyone noodled through the details of pxeboot and pc-sysinstall for automated installs? I have working configurations for pxeboot and sysinstall for 8.1-RELEASE and prior. What are the gotchas for 9.0-CURRENT? I have lots of testing time available. Thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: setfacl Recursive Functionality
Included in the attached patch is the refactor using fts(3) and with the -L and -H options. I'm still looking for feedback and suggestions on how to improve the patch. I'll also port these changes over to my getfacl patch. If anyone's interested in following up-to-date development of the patch, the link to it on github is https://github.com/lattera/patches/blob/master/freebsd/setfacl_recursive.patch I'd like to take the time to address why I created the remove_invalid_inherit function since I got a private email asking why it existed. Other than symbolic links, non-directory entries cannot have inheritance set. That function prevents attempting to set inheritance flags on non-directory entries when doing a recursive call. That way, you can run `setfacl -R -m user::read_data:file_inherit/dir_inherit:allow ` and not run into errors. Thanks, Shawn On Tue, Feb 8, 2011 at 7:51 PM, Shawn Webb wrote: > On Tue, Feb 8, 2011 at 7:35 PM, Tim Kientzle wrote: > >> On Feb 8, 2011, at 9:58 AM, Shawn Webb wrote: >> > I've just finished a patch to add recursive functionality to setfacl. >> Before >> > I officially submit it, I'd like a few suggestions on how to improve the >> > patch. >> > >> > The part I'm worried about involves the #define directive at top. I'm >> not >> > sure what ramifications using that define might have. I needed it for my >> > remove_invalid_inherit() function to work. >> >> You should certainly not need >> #define _ACL_PRIVATE >> for any user-space utilities. What exactly is the >> problem without that? >> >> Your approach to directory walking here >> is a little simplistic. In particular, you're storing >> every filename for the entire tree in memory, >> which is a problem for large filesystems. >> >> It would be much better to refactor the code so that >> the actual ACL update was in a function and then >> recurse_directory should call that function for >> each filename as it visited it. That will reduce >> the memory requirements significantly. >> >> You should also take a look at fts(3). In particular, >> you'll want to implement the BSD-standard >> -L/-P/-H options, and fts(3) makes that much easier. >> (-L always follows symlinks, -P never follows symlinks, >> -H follows symlinks on the command line). >> >> Tim >> >> > Great suggestions. I'll definitely look at implementing that functionality. > > As a side note, it looks like my setfacl patch segfaults on freebsd-current > r218075 with the zpool v28 patchset applied. I wrote it on freebsd 8.2-RC3 > with zpool v15. > > Thanks, > > Shawn > setfacl_recursive.patch Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: new dialog/libdialog testing
On Wed, Feb 09, 2011 at 10:28:53AM -0500, David Boyd wrote: > Having some time to test 9.0-CURRENT with the new dialog command has > uncovered only one major omission (for us): prgbox/dialog_prgbox. > > This is used in most (if not all) of our installation/management scripts. > > Was prgbox omitted for any particular reason? > > I realize that change is inevitable. > > Is there a better approach to running a program in a window? > > We like many of the new features presented, but are wary of problems down > the road due to the omission of prgrbox. > > I notice that sysinstall uses dialog_prgbox in 8.1-RELEASE. I've had that widget (and a few others - tree and build-list) on my to-do list for a while, but don't recall noticing that the unimplemented ones were used much. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgprNz2N0qkmK.pgp Description: PGP signature
Re: pc-sysinstall and pxeboot
On Wed, Feb 9, 2011 at 12:13 PM, David Boyd wrote: > Has anyone noodled through the details of pxeboot and pc-sysinstall for > automated installs? > > I have working configurations for pxeboot and sysinstall for 8.1-RELEASE and > prior. > > What are the gotchas for 9.0-CURRENT? > > I have lots of testing time available. I have done something in this realm called vCloudFreeBSD but I have not set it up as a pxeboot. I am sure you could very easily. vCloudBSD is meant to auto install to the first available disk. This ISO contains the Puppet packages and will automatically join a puppet server and self configure but you can pull the bits and pieces out and roll your own disk using the pfSense builder framework or the traditional make release methods. If you are interested in learning more I talk about it in my blog. http://scottullrich.posterous.com/ Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Increasing TCP Window Size in FreeBSD.
I have been using iperf in server mode to do some performance analysis. I was trying to increase the Receive TCP Window Size via sysctl net.inet.tcp.recvspace= I noticed that I could increase it atmost to 128Kbytes (131072). Any value above 128k, results in a failure to get the requested window size, resulting in a failure of "iperf -s -w ". How can I increase it beyond 128Kbytes ? Here are some relevant sysctl values I have been using: net.inet.tcp.rfc1323: 1 net.inet.tcp.recvspace: 131072 net.inet.tcp.recvbuf_max: 4096000 net.inet.tcp.recvbuf_inc: 65536 net.inet.tcp.recvbuf_auto: 1 Thanks david S. This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: Increasing TCP Window Size in FreeBSD.
You may have to tune few more - kern.ipc.maxsockbuf, kern.ipc.nmbclusters. http://www.cs.unc.edu/~jeffay/dirt/FAQ/sobuf.html http://people.freebsd.org/~adrian/sysctl.descriptions Regards, Gireesh -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of David Somayajulu Sent: 10 February 2011 10:24 To: freebsd-current@freebsd.org Subject: Increasing TCP Window Size in FreeBSD. I have been using iperf in server mode to do some performance analysis. I was trying to increase the Receive TCP Window Size via sysctl net.inet.tcp.recvspace= I noticed that I could increase it atmost to 128Kbytes (131072). Any value above 128k, results in a failure to get the requested window size, resulting in a failure of "iperf -s -w ". How can I increase it beyond 128Kbytes ? Here are some relevant sysctl values I have been using: net.inet.tcp.rfc1323: 1 net.inet.tcp.recvspace: 131072 net.inet.tcp.recvbuf_max: 4096000 net.inet.tcp.recvbuf_inc: 65536 net.inet.tcp.recvbuf_auto: 1 Thanks david S. This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
