RE: jail and networking
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of d...@safeport.com Sent: Thursday, February 21, 2013 11:00 AM To: Shane Ambler Cc: freebsd-questions@freebsd.org; Bernt Hansson Subject: Re: jail and networking On Thu, 21 Feb 2013, Shane Ambler wrote: It's been a while since I experimented with jails but I'm pretty sure it is the reason I changed my sshd_config When you start sshd on the base system by default it binds against 0.0.0.0 and :: which is every ip4 and ip6 address configured on the base system, which includes the aliased ip's for your jails. This is represented by the *:22 from sockstat. When you start the jail it can't start sshd because the base already has that address/port in use. In /etc/ssh/sshd_config comment out the ListenAddress 0.0.0.0 and ListenAddress :: then add ListenAddress 10.0.0.3 service sshd restart start your jail and try again The jail config is fine as the jail only sees the one ip address assigned to it. This is what fixed the problem. From the jail man page, ... The following frequently deployed services must have their individual configuration files modified to limit the application to listening to a specific IP address It then specifically mentions ssh and send mail. The system I looked at runs seven jails fine without my having made that change. I am not sure why I am getting away with this, but I also thank you What I find strange is that: 1. I knew about ListenAddress w/respect to jails, but... 2. We are not changing it (sshd_config has no ListenAddress -- leading to default values used), yet... 3. Base machine and jails both work fine Not sure when it's required versus not, because we're running fine without that change here with over a dozen jails. The only thing I've ever noticed is that we tend to use jail_NAME_ip=iface|addr while most everybody else seems to be using jail_NAME_ip=addr. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
ZFS Question
Hi, What's the difference between: zpool create -m /desired_destination POOL_NAME disk_device and zpool create -m none POOL_NAME disk_device zfs create -m /desired_destination POOL_NAME/foo We would prefer the former, but see more uses of the latter. The whole point is that we want to keep things simple and having only a single mount-point makes things simpler, but I'm curious about any possible fallbacks to using just the pool on the mount point with zero filesystems created underneath. In other words... does zfs create actually buy us anything versus just using the pool mounted on the desired location? -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: building crunchgen fails
On Jan 23, 2013, at 8:44 AM, Rick Miller wrote: On Wed, Jan 23, 2013 at 11:01 AM, Devin Teske devin.te...@fisglobal.com wrote: On Jan 23, 2013, at 7:22 AM, Rick Miller wrote: Hi All, When executing crunchgen -o boot_crunch.conf make -f boot_crunch.mk I get the following error: cc -static -o boot_crunch boot_crunch.o hostname.lo pwd.lo rm.lo sh.lo ls.lo test.lo cat.lo df.lo sleep.lo camcontrol.lo dhclient.lo fsck_ffs.lo ifconfig.lo mount_nfs.lo newfs.lo route.lo rtsol.lo tunefs.lo kenv.lo sysctl.lo mdmfs.lo dmesg.lo fdisk.lo bsdlabel.lo uname.lo cpio.lo find.lo minigzip.lo sed.lo awk.lo fetch.lo arp.lo sysinstall.lo usbconfig.lo grep.lo -lcam -lsbuf -lutil -ll -ledit -lfetch -lmd -lcrypt -lftpio -lz -lnetgraph -ldialog -lncurses -ldisk -lufs -ldevinfo -lkvm -lgeom -lbsdxml -larchive -lbz2 -lusb -lgnuregex -llzma -lssl -lcrypto -ljail -lm camcontrol.lo(.text+0x730b): In function `main': : undefined reference to `mode_edit' camcontrol.lo(.text+0x73fa): In function `main': : undefined reference to `mode_list' *** Error code 1 Stop in /tmp/crunchtmp. I understand that there may need to be some shuffling of the libraries in the boot_crunch.conf, but I've done that to no avail. Wondering if anyone else may be able to shed some light on this... The boot_crunch.conf can be viewed at https://urldefense.proofpoint.com/v1/url?u=http://pastebin.com/ZwVPQn3hk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=Hnn4NG9Hyf8%2F%2F0%2FFE6hjIC649weMNcRXdV4V8oYmXGs%3D%0As=a3915bb0ab3862b707fc373a12f153257c6a06b1ee05925c9714f88fc81d783b According to the Makefile, if RELEASE_CRUNCH is defined, then modeedit.o object is omitted (causing your undefined references). I perceive the long-term real solution would be to patch camcontrol.c (and pedantically camcontrol.h) to not use mode_edit()/mode_list() when RELEASE_CRUNCH is defined. However, you should be able to get through your problem by adjusting your boot_crunch.conf slightly: Try https://urldefense.proofpoint.com/v1/url?u=http://pastebin.com/Ge6UCZEZk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=Hnn4NG9Hyf8%2F%2F0%2FFE6hjIC649weMNcRXdV4V8oYmXGs%3D%0As=27ceca7c7f03287568ea4d5c6af082fdf0e1182cdd8b90841429dd7d55752e42 The difference being: --- boot_crunch.conf.orig 2013-01-03 16:29:20.0 -0800 +++ boot_crunch.conf2013-01-03 16:29:13.0 -0800 @@ -17,6 +17,7 @@ srcdirs /usr/src/sbin progs camcontrol +special camcontrol objs camcontrol.o modeedit.o util.o progs dhclient progs fsck_ffs progs ifconfig Thanks, Devin! That worked...which Makefile did you find this in? sbin/camcontrol/Makefile -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: bsdinstall(8) line drawing characters
On Jan 19, 2013, at 8:23 PM, David Lazaro Saz wrote: Hi, I've tried to find an answer to this question without success. Why does bsdinstall(8) use ASCII characters for drawing lines instead of line drawing characters as the old sysinstall(8) did? A different theory… It should be noted that sysinstall uses an older version of libdialog (which in 9.x was moved to libodialog). Here's a side-by-side comparison of libodialog (left) and libdialog (right): http://druidbsd.sf.net/download/bsdconfig/MediaCompareFTP.png In that case, $TERM was xterm-256color running via Apple's Terminal.app. Of interest I would think is the output of: dialog --version echo $TERM and whether (if possible) sysinstall produces similar results (what release are you running?) -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Problems with diskless/nfs
On Jan 20, 2013, at 5:12 AM, Bernt Hansson wrote: Hello list! I'm trying to set up a diskless workstation, but I fail. The boot process stops at Can't find kernel then the OK prompt appear. In the log I have this: mountd[1200]: mount request denied from 10.0.0.6 for /news/spool/ad16/x86 pxeboot loads but can't find the kernel because of this. in inetd.conf I have this for tftpd tftpdgram udp waitroot/usr/libexec/tftpd tftpd -l -s /news/spool/ad16/x86 It seems like it is some problem with nfs. Any help is welcome. What's the output of (on the pxeboot/tftp/dhcp server): $ showmount -e | grep ^[[:space:]]*/news/spool/ad16/x86 (empty? it shouldn't be) $ grep ^[[:space:]]*/news/spool/ad16/x86 /etc/exports (empty? it shouldn't be) -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Jails
On Jan 14, 2013, at 10:12 PM, Zyumbilev, Peter wrote: On 15/01/2013 02:10, Leonardo M. Ramé wrote: Yes, and also defined /etc/resolv.conf. Any hint? Leonardo M. Ramé http://leonardorame.blogspot.com This is my jail conf. jail_debian_rootdir=/jail/debian jail_debian_hostname=debian.bivol.net jail_debian_ip=192.168.30.12 jail_debian_interface=bge0 NOTE: You can optionally combine/collapse those last 2 lines into one: jail_debian_ip=bge0|192.168.30.12 (with the pipe character [|] separating the interface and IP) -- Devin jail_debian_devfs_enable=YES jail_debian_devfs_ruleset=devfsrules_jail jail_debian_flags=-n debian #jail_debian_mount_enable=YES # mount YES|NO jail_debian_fstab=/jail/conf/fstab.debian you have ip interface settings correct ? Mine card is bge0, but your one might be different. Peter ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Jails
On Jan 13, 2013, at 7:45 AM, Leonardo M. Ramé wrote: From: Zyumbilev, Peter pe...@aboutsupport.com To: freebsd-questions@FreeBSD.org Cc: Mark Felder f...@feld.me; Devin Teske dte...@freebsd.org; Devin Teske devin.te...@fisglobal.com Sent: Sunday, January 13, 2013 7:09 AM Subject: Re: Jails On 12/01/2013 18:41, Devin Teske wrote: On Jan 11, 2013, at 11:31 PM, Zyumbilev, Peter wrote: Hi, I have not tested it, but so far things do not look promising... I cannot even run netstat -nvatp properly, however sopcast seemed to run, but have not tested it, for plex - have not tried yet. netstat isn't allowed in traditional jails (but is allowed in vimage jails which have their own network stack). If you're able/willing to compile a new kernel to enable the VIMAGE feature, then this can be improved so that you can indeed use netstat within the jail. NOTE: netstat is not allowed within traditional (non-VIMAGE) jails due to security restrictions. My host os is Nas4Free and is stripped version of freebsd - e.g I cannot even compile ports - that is why I use jails - so no new kernel for me there :) So far I am quite happy with it - I use it mainly as DLNA server(Serviio), ZFS,UPS support Transmission made it quite good platform - would take plenty of time to get all this in plain FreeBSD install. The only thing that I might be missing is Plex, but due to lack browser per folder feature, I will stick to open standard - DLNA. Peter Hi, I've installed debian 6 in a jail, from FreeBsd 9.1 x86-64 by following the instructions from this thread. However, I also updated my /etc/resolv.conf inside the jail, but I get this error when I do ping: ping is usually denied from within a jail (for security purposes). Add the following to /etc/rc.conf: jail_sysvipc_allow=YES And then reboot. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Reading the handbook from console
On Jan 13, 2013, at 12:15 PM, Fbsd8 wrote: Polytropon wrote: On Thu, 10 Jan 2013 14:48:33 -0800, dte...@freebsd.org wrote: -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Polytropon Sent: Thursday, January 10, 2013 2:33 PM To: Fbsd8 Cc: scotteb...@gmail.com; questi...@freebsd.org Subject: Re: Reading the handbook from console On Thu, 10 Jan 2013 13:57:47 -0500, Fbsd8 wrote: Scott Eberl wrote: I went ahead and installed the FreeBSD handbook onto my system and I was able to find it on disk per the motd notes but I'm wondering if there is a preferred method for reading these since they are in html format. I tried w3m and lynx and it looks like they are both not installed. Is there something i'm missing for reading these or do I just need to install a cli browser? Viewing html takes some form of browser. There is no text mode web browser in the base system. Installing one is easy: As the HTML files generated for the Handbook are good quality, they display nicely in lynx, links, and w3m (probably the most prominent three text mode web browsers). I must know... What is Polytropon's favorite of those listed? (and perhaps also elinks ?) Hard to say, now that X is everywhere... :-) In the past, I've started using lynx because it was the default. Somehow I even tend to remember that it was part of the default installation in around FreeBSD 4 or so... but that could be wrong. Later on I tried w3m and also found it usable. Today I'd say I prefer links for interactive text mode browsing. Still lynx -dump is a welcome tool in some of my scripts, and never change a running system. :-) Reading the pkg-descr of elinks it seems to bring lots of extensions, some interesting, some not that interesting (at least for the use discussed here: reading FreeBSD supplied local documentation: no need for cookies, scripts, or HTTP referers). Other features like the ability to render tables might be a reason not to use a browser that cannot do this (maybe lynx can't?). (and do you enable console graphics?) No, I have to admit that I've never even _tried_ that. Somehow deep inside my brain there's the statement that graphics in console mode is libvga which is for Linux, not for FreeBSD, but that might not apply anymore. However, The FreeBSD Handbook and the FAQ mostly contain text, I mean, that's what they are about, and for reading text I don't see a need for graphics. If I want graphics, I have X. :-) What do you mean by enable console graphics? Is this something different than x11? Yes, some console-based browsers support displaying graphics directly on the console (read: ttyv*). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Reading the handbook from console
On Jan 13, 2013, at 4:01 PM, Fbsd8 wrote: Robert Bonomi wrote: Date: Sun, 13 Jan 2013 21:48:01 +0100 From: Polytropon free...@edvax.de To: Fbsd8 fb...@a1poweruser.com Subject: Re: Reading the handbook from console Cc: scotteb...@gmail.com, dte...@freebsd.org, questi...@freebsd.org On Sun, 13 Jan 2013 15:15:23 -0500, Fbsd8 wrote: What do you mean by enable console graphics? Is this something different than x11? The is a famous library, svgalib, a low level console graphics library which can - under _very_ specific circumstances - display graphics on the text mode console. There are few browsers, image viewers and even media players that can use this interface to display console graphics while _not_ needing X. However, this only works for local displays. As soon as there is a serial or SSH connection involved, it doesn't work anymore. I've actually never seen this working on FreeBSD; maybe it's just a Linuxism. Maybe it's just because I've never tried. :-) Works fine on FreeBSD -- graphics-mode screen-savers (like 'fire') use it. How do you activate graphics-mode screen-savers (like 'fire')? Try adding to /boot/loader.conf: screensave_load=YES screensave_name=fire_saver -- Devin P.S. The default is green_saver (which blanks the console, saving energy making it green). _ 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Jails
On Jan 11, 2013, at 11:31 PM, Zyumbilev, Peter wrote: Hi, I have not tested it, but so far things do not look promising... I cannot even run netstat -nvatp properly, however sopcast seemed to run, but have not tested it, for plex - have not tried yet. netstat isn't allowed in traditional jails (but is allowed in vimage jails which have their own network stack). If you're able/willing to compile a new kernel to enable the VIMAGE feature, then this can be improved so that you can indeed use netstat within the jail. NOTE: netstat is not allowed within traditional (non-VIMAGE) jails due to security restrictions. -- Devin On 11/01/2013 21:19, Mark Felder wrote: On Fri, 11 Jan 2013 18:28:41 +0200 Zyumbilev, Peter pe...@aboutsupport.com wrote: 1. Use http://download.openvz.org/template/precreated/debian-6.0-x86.tar.gz instead the file listed in the howto. 2. Run sysctl compat.linux.osrelease=2.6.32 in Freebsd shell before starting the jail, otherwise you will get error kernel too old. Does PLEX work? I'm highly interested in this I even posted asking for FreeBSD support on the relevant forum post... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: 9.0 vs 9.1
If you add $PACKAGESITE to your environment you can fetch just fine with pkg_add -r Example… env PACKAGESITE=ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9-stable/Latest/ pkg_add -r irssi -- Devin On Jan 10, 2013, at 6:02 PM, Scott Eberl wrote: OK can someone please explain this to me in detail? I've been reading all the release notes I can find and I'm not understanding why after upgrading to 9.1 I have to compile from source to install stuff now. It takes forever and asks me questions I have no idea what the answer is to. Early today I installed irssi which I had to do with make clean install because just doing pkg_add -r irssi complains about not being able to find the url of it. Should I just reinstall 9.0 and not upgrade, will ports work correctly then? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Renaming files
On Jan 9, 2013, at 9:29 PM, Odhiambo Washington wrote:
I have several files in this format:
rw-r--r-- 1 johndoe johndoe20085 Jan 9 19:30 1357744249.26989.mbox:2,
-rw-r--r-- 1 johndoe johndoe24419 Jan 9 19:30
1357744250.26989.mbox:2,
-rw-r--r-- 1 johndoe johndoe 418 Jan 9 19:30
1357744251.26989.mbox:2,
-rw-r--r-- 1 johndoe johndoe 418 Jan 9 19:30
1357744252.26989.mbox:2,
-rw-r--r-- 1 johndoe johndoe78426 Jan 9 19:30
1357744254.26989.mbox:2,
-rw-r--r-- 1 johndoe johndoe 2561 Jan 9 19:30
1357744255.26989.mbox:2,
-rw-r--r-- 1 johndoe johndoe 6971 Jan 9 19:30
1357744257.26989.mbox:2,
-rw-r--r-- 1 johndoe johndoe11270 Jan 9 19:30
1357744259.26989.mbox:2,
I'd like to rename them so that the filenames are in the format below:
-rw--- 1 johndoe johndoe 197702 Jan 10 03:00
1357776052.V803I33939aM83469.mail.domain.me.net:2,
-rw--- 1 johndoe johndoe 14579 Jan 10 03:31
135873.V803I33939bM614733.mail.domain.me.net:2,
-rw--- 1 johndoe johndoe 29212 Jan 10 03:46
1357778798.V803I33939cM995892.mail.domain.me.net:2,
-rw--- 1 johndoe johndoe2834 Jan 10 04:30
1357781421.V803I33939dM597872.mail.domain.me.net:2,
-rw--- 1 johndoe johndoe 10593 Jan 10 06:18
1357787890.V803I33939eM865700.mail.domain.me.net:2,
-rw--- 1 johndoe johndoe 43565 Jan 10 07:10
1357791044.V803I33939fM193189.mail.domain.me.net:2,
-rw--- 1 johndoe johndoe 15492 Jan 10 07:42
1357792926.V803I3393a0M601349.mail.domain.me.net:2,
The first part of the filename is unique, so I just need to substitute
26989.mbox:2, with V803I33939aM83469.mail.domain.me.net:2, hoping there
will be no clash:(
sh -c 'for file in *.26989.mbox:2; do mv $file
${file%%.*}.V803I33939aM83469.mail.domain.me.net:2; done'
--
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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: somewhat OT ... in parts
On Jan 3, 2013, at 11:03 PM, Polytropon wrote: On Thu, 3 Jan 2013 18:27:38 -0800, Gary Kline wrote: one question I have may solve the problem of vim displaying all the ^/search terms and displaying them in some color. the default brown is awful, but dark blue isn't much bbetter. If you try :colorscheme blue you can see that the results have orange background with dark text (maybe black?), while the editor background is blue (as the name of the color scheme suggests). So: can I add something to my ~/.vimrc that =limits= the search to displaying one term? if I am searching for, say, the or I guess /\the\, I dont want every the in my file. I want only one. or one at a time, and not necessarily in color. If you have :set hlsearch activated, all (visible) matches will be highlighted, :set hls :set nohls for short to enable/disable (respectively). and the cursor will be placed at the first match. On a side note, there's also :set incsearch That will make you jump ahead as you type (I personally don't care for it). I don't see an option to highlight the _next_ result only. However, if you do _not_ set hlsearch, searching and continuing searching will not highlight anything, instead let the cursor skip to the next match (tried here with gvim /COPYRIGHT, /this, /, /, / and so on), with :set nohlsearch for testing. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: somewhat OT ... in parts
On Jan 3, 2013, at 5:44 AM, Rod Person wrote: On Wed, 2 Jan 2013 18:53:05 -0800 Gary Kline kl...@thought.org wrote: thanks in advance for a few url's. I love this color scheme, I use it for everything. There is a vim specific version...http://ethanschoonover.com/solarized On the vim-specific page ( https://github.com/altercation/vim-colors-solarized ), it has a section Important note for terminal users. Q: Did you do what it said in that section? or do you only use the vim colorscheme? Q: If you customized your terminal colors with solarize, does it work out alright in various situations? (for example, putty versus Mac OS X Terminal versus physical FreeBSD console, et cetera) -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: about unattended installation
On Dec 20, 2012, at 3:34 AM, Egoitz Aurrekoetxea Aurre wrote: Good morning, El 19/12/2012, a las 19:59, Devin Teske devin.te...@fisglobal.com escribió: On Dec 19, 2012, at 10:06 AM, Egoitz Aurrekoetxea Aurre wrote: Good afternoon, One little question… I'm trying to have ready our new unattended FreeBSD installation system. Until now, I have been using Sysinstall scripting file but now with 9.1 out I think it's moment to start using BSDInstaller in the unattended installation process. Hold on a moment. You might want to wait until 9.2. (read more below) Well in the ftp can be seen : FreeBSD-9.1-RELEASE-amd64-disc1.iso downloadable file…. so I assume it's a release??? Of course it's a release… it just may not be the release that solves your problem w/respect to scripting bsdinstall like sysinstall. That will come in a future release (like 9.2). I have seen the new installer, works basically like an script…. my real question is… before I did in install.cfg something like : disk=da0 partition=all bootManager=standard diskPartitionEditor da0s1-1=ufs 3072000 / da0s1-2=swap 8096000 none da0s1-3=ufs 20485760 /var 1 da0s1-4=ufs 30720760 /usr 1 da0s1-5=ufs 0 /expert 1 diskLabelEditor Now I assume there's no way of getting this same through any command like… 'bsdinstall partedit ___' am I wrong??. You're correct. In 9.0 and 9.1, it's just not feasible to man-handle the user interface (partedit) as one could sysinstall. (read below about 9.2) So I suppose that till the new installer is able to handle this in a similar way to sysinstall (although the syntax to be different or whatever)…. or partitioning can be achieved in some non interactive way, to maintain the possibility of rebuilding one's own release in order to be able to use sysinstall and to be able to maintain working unattended installation systems…. because this is essential for some of us….. and of course sysinstall to still continue working :)… You got it. This is a sign to the releng team and everybody else that 10.0 should most-likely not see the light of day until bsdinstall can pass the sniff-test for those of us (like you and I) which rely on the ability to script the installation process fully. So I assume all should be done by hand like this example of the Handbook : # dd if=/dev/zero of=/dev/da1 bs=1k count=1 # fdisk -BI da1 #Initialize your new disk # bsdlabel -B -w da1s1 auto #Label it. # bsdlabel -e da1s1 # Edit the bsdlabel just created and add any partitions. # mkdir -p /1 # newfs /dev/da1s1e # Repeat this for every partition you created. # mount /dev/da1s1e /1 # Mount the partition(s) # vi /etc/fstab # Add the appropriate entry/entries to your /etc/fstab. In the auto script…. am I wrong?. If the answer is yes… could you point me to some documentation in order to be able to complete all this doc. The answer is (unfortunately) yes… that is until (hopefully) 9.2. It's an on-going significant amount of work to make add backward compatibility (so bsdinstall can load sysinstall install.cfg files). I'm not going to discuss the specifics here or yet, but I'm actively working on it. No docs on how to mangle the auto script to do what you want (that I know of). Ok then :) Apart from all this… is Sysinstall going to be maintained in parallel?. Sysinstall is dead. Devin, sysinstall should not be died till the new installer allows or exists a way of doing same thing than before we did in some manner or other one….. And, you're absolutely right. Some facts/history: a. I'm not the one that killed it (on the contrary, like yourself, I was vehemently arguing against its death -- like you say, UNTIL whatever replacement could offer the same features). ASIDE: You can see my arguing the same points your making now at the below link to the mailing-list archives: http://lists.freebsd.org/pipermail/freebsd-sysinstall/2011-February/000369.html ASIDE: There's a lot of arguments for keeping sysinstall in the above-linked mailing-list, but at the end of the day, we have to realize that sysinstall was not being worked on to provide the features that the angry mob of users was demanding (GPT, ZFS, Geli, etc.) so the 15-year inertia that sysinstall enjoyed had to be ended. There will be people like yourself and me that disagree with the timeline of events that led to the demise of sysinstall in the 10.0-CURRENT line, but all I can say is that there is Ron McDowell (may he rest in peace) vehemently recognized the short-coming and dedicated our lives to filling it (and for Ron, actually the final year of his life was spent working on this project -- a truly selfless act if there ever was one). b. It's officially dead in the 10.0-CURRENT line (read
Re: about unattended installation
On Dec 19, 2012, at 10:06 AM, Egoitz Aurrekoetxea Aurre wrote: Good afternoon, One little question… I'm trying to have ready our new unattended FreeBSD installation system. Until now, I have been using Sysinstall scripting file but now with 9.1 out I think it's moment to start using BSDInstaller in the unattended installation process. Hold on a moment. You might want to wait until 9.2. (read more below) I have seen the new installer, works basically like an script…. my real question is… before I did in install.cfg something like : disk=da0 partition=all bootManager=standard diskPartitionEditor da0s1-1=ufs 3072000 / da0s1-2=swap 8096000 none da0s1-3=ufs 20485760 /var 1 da0s1-4=ufs 30720760 /usr 1 da0s1-5=ufs 0 /expert 1 diskLabelEditor Now I assume there's no way of getting this same through any command like… 'bsdinstall partedit ___' am I wrong??. You're correct. In 9.0 and 9.1, it's just not feasible to man-handle the user interface (partedit) as one could sysinstall. (read below about 9.2) So I assume all should be done by hand like this example of the Handbook : # dd if=/dev/zero of=/dev/da1 bs=1k count=1 # fdisk -BI da1 #Initialize your new disk # bsdlabel -B -w da1s1 auto #Label it. # bsdlabel -e da1s1 # Edit the bsdlabel just created and add any partitions. # mkdir -p /1 # newfs /dev/da1s1e # Repeat this for every partition you created. # mount /dev/da1s1e /1 # Mount the partition(s) # vi /etc/fstab # Add the appropriate entry/entries to your /etc/fstab. In the auto script…. am I wrong?. If the answer is yes… could you point me to some documentation in order to be able to complete all this doc. The answer is (unfortunately) yes… that is until (hopefully) 9.2. It's an on-going significant amount of work to make add backward compatibility (so bsdinstall can load sysinstall install.cfg files). I'm not going to discuss the specifics here or yet, but I'm actively working on it. No docs on how to mangle the auto script to do what you want (that I know of). Apart from all this… is Sysinstall going to be maintained in parallel?. Sysinstall is dead. The bsdinstall you know can be considered the first generation and accordingly is a bit spartan. I'm working hard on the next generation. My plan is to have 10.0 with bsdinstall able to run sysinstall scripts (for backward compatibility; can't yet say what 9.x release will be MFC'd to, but that could be 9.2). I'm planning one helluva BSDCan-2013 presentation. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: about unattended installation
On Dec 19, 2012, at 10:52 AM, Amitabh Kant wrote: Won't be able to help you much, but bsdinstall seems to be using gpart rather than fdisk. This page has a nice explanation on how to use gpart: http://www.wonkity.com/~wblock/docs/html/disksetup.html As for sysinstall, it's not being mainitned officially, but http://druidbsd.sourceforge.net/ is using sysinstall Cool! I'm the maintainer of FreeBSD Druid (sysinstall-based 9.x installer). When 9.1 is officially announced, I'll start rolling a new 9.1 based installer (right now, still just 8.3 and 9.0 are the latest offerings). I'm also the maintainer of bsdconfig. I'd like to also think I'm that last unofficial maintainer of sysinstall (I've actually patched it in stable/9 in the past 90 days). And, as-of the last DevSummit, I've been nominated the new maintainer of bsdinstall (with nwhitehorn's blessing). So… At some point, you'll see me go rabid on all the PR's in the freebsd-sysinstall pool, but right now I'm still in the coal-mines dredging out the framework to accept all these missing features. -- Devin On Wed, Dec 19, 2012 at 11:36 PM, Egoitz Aurrekoetxea Aurre ego...@ramattack.net wrote: Good afternoon, One little question… I'm trying to have ready our new unattended FreeBSD installation system. Until now, I have been using Sysinstall scripting file but now with 9.1 out I think it's moment to start using BSDInstaller in the unattended installation process. I have seen the new installer, works basically like an script…. my real question is… before I did in install.cfg something like : disk=da0 partition=all bootManager=standard diskPartitionEditor da0s1-1=ufs 3072000 / da0s1-2=swap 8096000 none da0s1-3=ufs 20485760 /var 1 da0s1-4=ufs 30720760 /usr 1 da0s1-5=ufs 0 /expert 1 diskLabelEditor Now I assume there's no way of getting this same through any command like… 'bsdinstall partedit ___' am I wrong??. So I assume all should be done by hand like this example of the Handbook : # dd if=/dev/zero of=/dev/da1 bs=1k count=1 # fdisk -BI da1 #Initialize your new disk # bsdlabel -B -w da1s1 auto #Label it. # bsdlabel -e da1s1 # Edit the bsdlabel just created and add any partitions. # mkdir -p /1 # newfs /dev/da1s1e # Repeat this for every partition you created. # mount /dev/da1s1e /1 # Mount the partition(s) # vi /etc/fstab # Add the appropriate entry/entries to your /etc/fstab. In the auto script…. am I wrong?. If the answer is yes… could you point me to some documentation in order to be able to complete all this doc. Apart from all this… is Sysinstall going to be maintained in parallel?. Thank you very much, Best regards! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD as VMWare guest / disk resizing
On Dec 18, 2012, at 6:35 AM, Luke Bakken wrote: You'll of course need to boot from another medium to do this. That's my main question - can a larger disk be detected *without* a reboot. On FreeBSD instances running within VMWare I have been able to add new disks without a reboot but, as I described below, have not found a way to get the operating system to detect a larger *existing* disk without a reboot. VMWare allows you to resize a disk on the fly. Obviously I'm only interested in the grow the disk scenario :-) I'm beginning to think a reboot is necessary, which is surprising! Live resize (without reboot even) is something being worked on for the future 10.x series. -- Devin On Dec 17, 2012, at 4:15 PM, Luke Bakken wrote: Hello everyone - I'm looking for a way to get FreeBSD 8 / 9 to detect that an already existing disk has grown. I have FreeBSD running as a guest within vSphere ESX 5. Here is the output of camcontrol showing how the disks are detected within the OS: [root@QA1HWFBSD83201 ~]# camcontrol inquiry da0 pass0: VMware Virtual disk 1.0 Fixed Direct Access SCSI-2 device pass0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Command Queueing Enabled In the VM settings I can increase the disk size but I can't seem to find the right command within FreeBSD to force it to detect the new, larger size without a reboot. 'camcontrol rescan all' works great to detect a new drive but doesn't detect a larger disk. Within a Linux distribution like Debian, the following command will detect the larger drive: echo 1 /sys/class/scsi_device/0:0:0:0/device/rescan I apologize if this has been answered in the archives or online but I just haven't been able to get a definitive answer if this is possible, and how. Thanks so much in advance, Luke ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: updatedb?
On Dec 18, 2012, at 1:01 PM, Walter Hurry wrote: $ sudo /usr/libexec/locate.updatedb WARNING Executing updatedb as root. This WILL reveal all filenames on your machine to all login users, which is a security risk. $ Why is it a security risk? Security through obscurity? Really? In this day and age? Or am I missing something? You're missing the fact that updatedb essentially makes a list of every file on your disk (and that this list is able to be queried by anybody regardless of permissions or group membership). The best and most notable example of this constituting a security risk is if you've prevented access to a directory… root's home-directory (/root) for example. Illustratively, this would be if you did chmod go-wrx somedir so that only the owner could see inside it. When you run updatedb as root, it traverses all directories even those that you may have posted a big keep out sign on (aforementioned chmod). Then every non-privileged user on the system can list the contents of your secret hideout with the keep out sign posted on it. You might have well built that house out of glass (they can't read the contents of the books on your bookshelf, but they can see the covers and know what you've got stocked on the shelves). If this doesn't concern you, (and there's plenty of reasons to ignore this warning -- say, if you operate in a closed environment where trust isn't an issue and you value the ability to find any file on the system at any time) -- then proceed my friend, … proceed. Otherwise, it's best to think about running updatedb as a non-privileged user that (a) can't use built-in super-user privileges to bypass security settings when enumerating the UNIX filesystems you've configured in locate.conf(5) (optional -- by default it acts sensibly and ignores what you'd expect it to). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Somewhat OT: Is Full Command Logging Possible?
On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote: On 12/18/2012 07:09 PM, Tim Daneliuk wrote: On 12/18/2012 06:53 PM, John Hein wrote: Tim Daneliuk wrote at 17:48 -0600 on Dec 5, 2012: On 12/05/2012 05:44 PM, Kurt Buff wrote: On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk tun...@tundraware.com wrote: I am working with an institution that today provides limited privilege escalation on their servers via very specific sudo rules. The problem is that the administrators can do 'sudo su -'. snip sudo is misconfigured. man 5 sudoers and man 8 visudo Kurt I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're saying. Are you suggesting that there is a way to configure sudo so that if someone does 'sudo su -' to become an admin, sudo can be made to log every command they execute thereafter? See log_input and log_output in sudoers(5) Thanks so much John, that's the secret sauce I was looking for... One further question, if I may. If I do this: sudo su - Will log_input record everything I do once I've been promoted to root? I ask because my initial experiments seem to show that all that's getting recorded is the content of the sudo command itself, not the subsequent actions… Correct, sudo is blind to the actions performed once the command requested is executed (in this case, su and subsequently a shell followed by more actions). I've suggested the lrexec module for catching everything, or you can look into the auditdistd (distributed auditing collection/collation to a remote/central server) approach, the praudit approach, or any of the other pieces of software mentions. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Somewhat OT: Is Full Command Logging Possible?
On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote: On 12/18/2012 07:33 PM, Devin Teske wrote: On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote: One further question, if I may. If I do this: sudo su - Will log_input record everything I do once I've been promoted to root? I ask because my initial experiments seem to show that all that's getting recorded is the content of the sudo command itself, not the subsequent actions… Correct, sudo is blind to the actions performed once the command requested is executed (in this case, su and subsequently a shell followed by more actions). Actually, I just tried this with both log_input and log_output options enabled. It seems that it *can* see into the promoted shell with a few caveats: - Command output is logged immediately, but command inputs appear to only be written to the log when you exit the promoted shell. This may be not quite right - there may have not been enough input to cause a write flush to the log. - The logging seems to be able to see into a spawned subshell, but I don't think it can see input/output if you, say, kick off an xterm. What about if you do sudo vim and then type :sh ? -- Devin I've suggested the lrexec module for catching everything, or you can look into the auditdistd (distributed auditing collection/collation to a remote/central server) approach, the praudit approach, or any of the other pieces of software mentions. _ 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Somewhat OT: Is Full Command Logging Possible?
On Dec 18, 2012, at 6:20 PM, Tim Daneliuk wrote: On 12/18/2012 08:03 PM, Devin Teske wrote: On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote: On 12/18/2012 07:33 PM, Devin Teske wrote: On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote: One further question, if I may. If I do this: sudo su - Will log_input record everything I do once I've been promoted to root? I ask because my initial experiments seem to show that all that's getting recorded is the content of the sudo command itself, not the subsequent actions… Correct, sudo is blind to the actions performed once the command requested is executed (in this case, su and subsequently a shell followed by more actions). Actually, I just tried this with both log_input and log_output options enabled. It seems that it *can* see into the promoted shell with a few caveats: - Command output is logged immediately, but command inputs appear to only be written to the log when you exit the promoted shell. This may be not quite right - there may have not been enough input to cause a write flush to the log. - The logging seems to be able to see into a spawned subshell, but I don't think it can see input/output if you, say, kick off an xterm. What about if you do sudo vim and then type :sh ? Yep, I just tried that too. It catches that. It also catches the in/output of subshells - like, say, kicking off sh interactively. Similarly, if you're running text-based emacs, it catches the output of spawning to a shell from there and doing things. The only restriction I have run into so far, it that - for obvious reasons - sudo cannot see into what you're doing if you kick off an X application like xterm or graphical emacs, for instance. What about screen or tmux? (wondering if the transition into multiplexed shell is anywhere as opaque as X11). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: using AWK
On Dec 17, 2012, at 3:39 AM, Jack Mc Lauren wrote:
Hi guys
How can I read a file which contains a number and assign that number to a
variable via awk programming? By the way, I want to use this awk program in a
shell script.
Thanks in advance
Try this:
awk -v file=/etc/ttys 'BEGIN { getline line file; printf First line from %s:
%s\n, file, line }'
--
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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: using AWK
On Dec 17, 2012, at 8:23 AM, Polytropon wrote:
On Mon, 17 Dec 2012 08:16:26 -0800, Devin Teske wrote:
On Dec 17, 2012, at 3:39 AM, Jack Mc Lauren wrote:
Hi guys
How can I read a file which contains a number and assign that number to a
variable via awk programming? By the way, I want to use this awk program in
a shell script.
Thanks in advance
Try this:
awk -v file=/etc/ttys 'BEGIN { getline line file; printf First line from
%s: %s\n, file, line }'
Or more verbose:
#!/bin/sh
filename=$1
echo file is ${filename} with content:
cat ${filename}
echo calling awk...
awk -v filename=$filename BEGIN {
getline no filename
close filename
print no
print no * 2
}
# EXAMPLE:
#
#
# % ./awkvar.sh /tmp/no.txt
# file is /tmp/no.txt with content:
# 12345
# calling awk...
# 12345
# 24690
The example shows how to use the variable inside awk. You
could get rid of the getline function in case the file
contains only the number you're interested in. If you need
further processing of the file, you can do that inside
awk (e. g. omitting comment lines, obtain data from a given
line number of specific pattern).
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
_
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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD as VMWare guest / disk resizing
It can be done but it's not easy and not pretty. You'll have to rewrite the partition scheme to grow *only* the last partition and then use growfs on the last partition to zero the new inodes within its newly defined range. You'll of course need to boot from another medium to do this. I usually use DruidBSD for this: DruidBSD-1.0b1.iso (a tiny 23.5MB ISO that you can write to thumb disk with dd or burn to cd; either works fine) Boot from it and use the tools like disklabel -e /dev/yourdisk But… be extremely careful and do your mathematics! I know this isn't a complete step-by-step guide, but I wanted to get the answer out there that this is possible and it's a known quantity, but it can be dangerous if you get the math wrong when editing the disklabel positions, for example. If you can get that part right, the rest is easy (growfs). -- Devin On Dec 17, 2012, at 4:15 PM, Luke Bakken wrote: Hello everyone - I'm looking for a way to get FreeBSD 8 / 9 to detect that an already existing disk has grown. I have FreeBSD running as a guest within vSphere ESX 5. Here is the output of camcontrol showing how the disks are detected within the OS: [root@QA1HWFBSD83201 ~]# camcontrol inquiry da0 pass0: VMware Virtual disk 1.0 Fixed Direct Access SCSI-2 device pass0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Command Queueing Enabled In the VM settings I can increase the disk size but I can't seem to find the right command within FreeBSD to force it to detect the new, larger size without a reboot. 'camcontrol rescan all' works great to detect a new drive but doesn't detect a larger disk. Within a Linux distribution like Debian, the following command will detect the larger drive: echo 1 /sys/class/scsi_device/0:0:0:0/device/rescan I apologize if this has been answered in the archives or online but I just haven't been able to get a definitive answer if this is possible, and how. Thanks so much in advance, Luke ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: mfsroot starts sysinstall how?
On Dec 12, 2012, at 7:50 AM, Rick Miller wrote: On Wed, Dec 12, 2012 at 10:44 AM, Rick Miller vmil...@hostileadmin.com wrote: Hi All, How is sysinstall invoked in a FreeBSD 8.x mfsroot.gz? It's actually invoked in the place of init(8). To explain more, I would like to boot into a shell as opposed to sysinstall. safe mode and single user don't seem to. Safe mode and single user won't work because sysinstall is acting as init and it doesn't implement those functions. To run a shell script in the place of init(8), you have to do some bootstrapping. Enter DruidBSD ( … not to be confused with previously discussed Druid [in another thread]). DruidBSD is a ~24MB ISO (~32MB if you get the version that has the extra tools like memtest86, etc.): http://druidbsd.sourceforge.net/download.shtml#DruidBSD Not only does it do what you're asking about … boot to a shell … but you can customize it. It uses the same build framework as the Druid (requiring GNU make, mkisofs, and [optionally] perl -- only required if you want the ISO to work from both CD/DVD _and_ USB thumb drive). You can download the source code, make changes to the custom /etc/rc which does the bootstrapping for you, and more -- then when finished, simply say gmake freebsd to produce your new custom media. It doesn't stop there… the /etc/rc that's in the mfsroot (link below): http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druidbsd/dep/freebsd/mfsroot/src/etc/rc?revision=1.1.1.1view=markup Is designed to bust you out of the mfsroot and bootstrap you not into a derelict sh(1) prompt, but instead a [more] usable bash(1) prompt complete with hundreds of extra utilities. PRO TIP: The Druid (which is the [much] larger ~500MB FreeBSD Installer that uses the same build framework) actually has a miniature version of DruidBSD tucked into its boot loader. That is to explain that when you use the FreeBSD Druid installer, the beastie boot menu has a fancy feature where you can select a different mfsroot from the menu (if you select the rescue_mfsroot then you're essentially invoking a custom version of DruidBSD, which we're talking about right now w/respect to replacing sysinstall(8) in an mfsroot with a bootstrap-to-interactive-shell). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: make release and mfsroot
Hi Rick,
If you want, you could follow my approach which is to take the completed
mfsroot.gz and use a Makefile to manage the creation of custom mfsroots
(keeping the original unmodified, making it simpler to test different
iterations).
The advantage is that you don't have to re-perform the release(7) process each
time you want to make a change to your mfsroot.
Check it out:
http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/dep/freebsd/mfsroot/standard/
Basically, you'd grab the Makefile (link below):
http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/dep/freebsd/mfsroot/standard/Makefile?revision=1.1
Then create a dep directory and src directory:
Next, take the virgin mfsroot.gz produced by the release(7) process and dump it
into the dep directory.
Next, put your install.cfg into the src directory (just like you see that I
did).
Optionally populate more files into the src directory (see the first link
above for an example -- example includes boot/modules/nullfs.ko, etc/fstab,
and etc/group, etc.).
When the src directory represents what you'd like to add to the mfsroot,
you're ready to produce a new copy of the stored original (at
dep/mfsroot.gz), complete with your additions.
Execute:
make from_dep
NOTE: sudo is required
What will happen is that dep/mfsroot.gz will be copied to the current working
directory, the mfsroot is ripped open (requires sudo privileges), the src
directory is layered onto the mfsroot, and finally the mfsroot is packaged back
up (leaving you with a custom ./mfsroot.gz for deployment).
--
Cheers,
Devin
On Dec 11, 2012, at 11:02 AM, Rick Miller wrote:
Hi All,
I generate a bootonly ISO and want to add files to the mfsroot.gz
created by the release.8 target. I want sysinstall to load an
install.cfg which makes a call to doconfig.sh. The target destination
for the files is stand/. My question is will the below patch
accomplish this for me provided install.cfg and doconfig.sh exist in
/usr/src/release?
# diff -u Makefile.orig Makefile
--- Makefile.orig 2012-12-11 18:15:29.0 +
+++ Makefile 2012-12-11 19:01:46.0 +
@@ -509,6 +509,7 @@
rm foo; \
fi
-test -f install.cfg cp install.cfg ${CHROOTDIR}/usr/src/release
+ -test -f doconfig.sh cp doconfig.sh ${CHROOTDIR}/usr/src/release
echo #!/bin/sh ${_MK}
echo set -ex ${_MK}
echo trap 'umount /dev || true' 0 ${_MK}
@@ -823,7 +824,9 @@
done
.endif
-test -f ${.CURDIR}/install.cfg \
- cp ${.CURDIR}/install.cfg ${RD}/mfsfd
+ cp ${.CURDIR}/install.cfg ${RD}/mfsfd/stand
+ -test -f ${.CURDIR}/doconfig.sh \
+ cp ${.CURDIR}/doconfig.sh ${RD}/mfsfd/stand
@mkdir -p ${RD}/mfsfd/boot
.if ${TARGET_ARCH} != ia64 ${TARGET_ARCH} != powerpc
@cp ${RD}/trees/base/boot/boot* ${RD}/mfsfd/boot
--
Take care
Rick Miller
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: make release and mfsroot
On Dec 11, 2012, at 1:50 PM, Rick Miller wrote: Hi Devin, On Tue, Dec 11, 2012 at 4:22 PM, Devin Teske devin.te...@fisglobal.com wrote: Hi Rick, If you want, you could follow my approach which is to take the completed mfsroot.gz and use a Makefile to manage the creation of custom mfsroots (keeping the original unmodified, making it simpler to test different iterations). Very interesting approach. I like it and will test it. It looks as though I would need to add code to the Makefile if files copied in later are greater in size than the space available. Would you agree? Oh… forgot to mention… The Makefile doesn't adjust the mfsroot's size. What I do to solve that problem is patch the release(7) process to make a bigger mfsroot (and thusly has room for more stuff) -- this allows me to keep the customizations of what goes in at a higher level (separate from release(7)) while not having to write a lot of code for resizing the mfsroot. NOTE: I've actually run into major problems with resizing an mfsroot -- trust me, it's safer to stick with bumping the sectors in the release(7) makefile. If you're working in the 8.x line, take a look at this patch for bumping the mfsroot size: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid83/dep/freebsd/patches/world_patches/release%3A%3AMakefile.patch?revision=1.1view=markup Meanwhile, for the 9.x line: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/dep/freebsd/patches/world_patches/release%3A%3AMakefile.sysinstall.patch?revision=1.1view=markup NOTE: For your purposes, you'll only need the first hunk (the second hunk is needed for other reasons -- reasons that are documented in the README one-level-up in the patches directory from the above links). The advantage is that you don't have to re-perform the release(7) process each time you want to make a change to your mfsroot. This is a very compelling advantage. Though, to resize the mfsroot, I still rely on release(7) and the above patches. I've personally never had a need to go beyond 6000 sectors, but I know the guys at Yahoo have gone much further. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: make release and mfsroot
On Dec 11, 2012, at 2:13 PM, Rick Miller wrote: On Tue, Dec 11, 2012 at 5:05 PM, Devin Teske devin.te...@fisglobal.com wrote: Though, to resize the mfsroot, I still rely on release(7) and the above patches. Here's another question, have you applied this approach to boot_crunch.conf? I simply replaced the default boot_crunch.conf with my own in the source tree. This is how I discovered MFSSIZE, because the resulting boot_crunch binary was larger than the available space. I've separated the various additions to mfsroot into two categories: 1. Additions that end up in the boot_crunch binary 2. All other additions I use the release(7) process to produce a custom mfsroot with finely tuned boot_crunch, then I use the previously-shared Makefile to put more files in (things that are separate from the boot_crunch). You can read more about my procedure here (complete recipe for customizing any part of the mfsroot, while spending as little time in the release(7) process as possible): http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/dep/freebsd/patches/README?revision=1.2view=markup The above is for the 9.x line, for the 8.x line the instructions are *slightly* different: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid83/dep/freebsd/patches/README?revision=1.1view=markup You can my customizations to boot_crunch: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/dep/freebsd/patches/local_patches/release%3A%3Ai386%3A%3Aboot_crunch.conf.patch?revision=1.2view=markup and again, slightly different for 8.x: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid83/dep/freebsd/patches/local_patches/release%3A%3Ai386%3A%3Aboot_crunch.conf.patch?revision=1.1view=markup -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Somewhat OT: Is Full Command Logging Possible?
On Dec 7, 2012, at 5:22 PM, Paul Schmehl wrote: --On December 7, 2012 10:23:56 AM +0100 Fleuriot Damien m...@my.gd wrote: On Dec 6, 2012, at 9:20 PM, Paul Schmehl pschmehl_li...@tx.rr.com wrote: --On December 6, 2012 1:19:00 PM -0600 Tim Daneliuk tun...@tundraware.com wrote: I understand this. Even the organization in question understands this. They are not trying to *prevent* any kind of access. All they're trying to do *log* it. Why? To meet some obscure compliance requirement they have to adhere to in order to remain in business. rant I know all of this is silly but that's our future when you let Our Fine Government regulate pretty much anything. /rant I sent this last night, but for some reason it never showed up. /usr/ports/security/sudoscript I believe this will meet your requirements. I'm sorry to say it won't. Nothing will prevent a user from removing sudoscript's FIFO once he gets root privileges. Well, sure, but, if someone logs in and sudos to root, that will be logged by sudoscript. If the logging then ceases, that would be cause for disciplinary action up to and including dismissal. What about the case of: sudo vim or sudo vim file Surely that wouldn't raise an eyebrow, but… Then execute within vim: :sh or ^_^ -- Devin … and another gem … sr env HOME=$HOME vim then :E _ 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Somewhat OT: Is Full Command Logging Possible?
On Dec 5, 2012, at 3:19 PM, Tim Daneliuk wrote: This is a little bit outside the strict boundaries of a FreeBSD question, but I am hoping someone in this community has solved this problem and that I might be able to adapt it for non-FreeBSD systems (AIX and Linux, specifically). I am working with an institution that today provides limited privilege escalation on their servers via very specific sudo rules. The problem is that the administrators can do 'sudo su -'. The fact that they became root is logged, *but everything thereafter they do is not*. What these people need is something that does the following things - this need not be sudo based, any FOSS or commercial solution would be considered: - Log the fact that someone became effective root - Log every command they execute *as* root - If they run a script as root, log the individual actions of that script - Have visibility into all this no matter how they access the system - console, ssh, xterm …. There's a kernel module floating around the Intarwebs… lrexec We used it for some years to satisfy governance regulations. But let me tell you… it got so noisy, it was ultimately disabled for sanity. But don't let that stop You. … Quick search of lrexec module yields the following: http://freebsd.munk.me.uk/archives/112-Installed-and-Configured-lrexec-module-For-Logging-System-Calls.html NOTE: Our plan for replacing this functionality in our organization was to use the praudit fire-hose available in FreeBSD-8.x. It too could be a solution to your problem. -- Devin Nothing I have found so far meets all these criterion. Verbose syslogging will not catch the case where you start a subshell from the main shell. Keylogging seems to only have limited coverage and does not appear it would work if, say, I log in via ssh and then kick off an xterm. Other solutions fail if I start an editor and shell out from there. The current proposal is to install sudo rules such that NO one is allowed 'sudo su -' and *every single command* you want to run as root has to start with 'sudo'. This has two big drawbacks: - It's an enormous pain for the admins and fundamentally changes their workflow - It cannot see into scripts. So I can circumvent it pretty easily with: sudo chown root:wheel my_naughty_script sudo chmod 700 my_naughty script sudo ./my_naughty_script The sudo log will note that I ran the script, but not what it did. So Gentle Geniuses, is there prior art here that could be applied to give me full coverage logging of every action taken by any person or thing running with effective or actual root? P.S. I do not believe auditd does this either. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: How do you manage jails?
On Nov 29, 2012, at 6:05 AM, Rick Miller wrote: Hi All, I want to inquire how the majority of users manage jails within their own environments. Do you use the utilities described in the handbook in chapter 16 or some other management facility like qjail or ezjail? I use my own home grown solution (freely available as a package): http://druidbsd.sf.net/vimage.shtml http://druidbsd.sf.net/download.shtml#vimage -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: How to allow httpd to run 'ipfw table 7 add ... '
On Nov 28, 2012, at 7:48 PM, Eugen Konkov wrote: Hi. How to allow httpd to run this command 'ipfw table 7 add ... '? imho the most secure way is to add an entry to sudoers(5) (you can use visudo(8) to edit sudoers(5)) allowing the apache privilege-separation user (www? we use apache here -- check your httpd.conf for User) to execute that specific command without a password. The entry might look something like this: apache ALL=(ALL) NOPASSWD: /sbin/ipfw That will allow the apache user to do things like: sudo ipfw table 7 add … because sudo will allow password-less privilege escalation to root (but only for ipfw, nothing else, for security reasons naturally). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Build a Distro using FreeBSD?
On Nov 22, 2012, at 11:25 AM, Matthew Seaman wrote: On 22/11/2012 18:20, Ron Blake wrote: I wanna make a distro but linux is too buggy for me so i thought about FreeBSD how do i go about building my own distro? Also are we allowed to make custom distros using FreeBSD please get back to me with info on building a custom distro using FreeBSD thanks. Sure, you can make your own 'distro' based on FreeBSD if you want, and distribute it under whatever terms you like. The BSD license is very liberal in this regard: more so than the GPL even. However, a 'distro' is a Linux concept that doesn't really apply very well to FreeBSD. We have a base system incorporating kernel, system libraries and all essential applications already: there's no need to gather all those things together to distribute to end users. There are disto-like things in BSD-land: PC-BSD and pfsense are a couple of interesting examples. These are essentially FreeBSD plus various additional software packages tuned for specific purposes (desktop usage in the case of PC-BSD, firewalls for pfsense) and it's this sort of value-added system built on top of the basic FreeBSD OS that is most likely to be successful as a distribution. If you still want to create your own distro, start by learning how to make your own customized install media. See the release(7) man page for starters, but you'll have to put some work in to come up anything significantly above and beyond the standard base system. It's not something you can just sling together in an afternoon… Matthew is right on all accounts. Once you feel that you've got a mental grasp of the release(7) process (link below): http://www.freebsd.org/cgi/man.cgi?query=releasesektion=7 If you find the need to make modifications to the source of the base operating system, try and digest my own recipe for creating DruidBSD from FreeBSD: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/dep/freebsd/patches/README?revision=1.2view=markup My recipe relies on the release(7) process and my howto shows how one might go about maintaining things. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: rc.conf and loader.conf
On Oct 25, 2012, at 5:17 PM, Ashkan Rahmani wrote: hi, what is the best order of items in rc.conf and loader.conf? actually items order is important? order does not matter (unless you have duplicates -- in which case later assignments override previous ones). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: MFS root filesystem and static binaries size
On Oct 17, 2012, at 1:30 AM, Steve O'Hara-Smith wrote: On Tue, 16 Oct 2012 13:13:41 -0700 Devin Teske devin.te...@fisglobal.com wrote: When two files have the same inode, they are hard links to each other. Unlike a soft link (or symbolic link as they are more appropriately called), which stores a destination-path of the target, a hard link instead looks and acts no different than the original in every way. A better way of thinking about it (ie. closer to reality) is that the inode entry is the file. When two directory entries both have the same inode number in them they refer to the same file. Crunchgen produces a file with a lot of names. For clarity/record, crunchgen(1) itself does not generate the links. You technically don't have to link to boot_crunch at all, for example: /stand/boot_crunch ls Another example: /rescue/rescue vi HINT: /rescue/rescue is also a crunchgen(1)-produced binary, just like /stand/boot_crunch in the mfsroot. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 8.x sysisntall dists
On Sep 27, 2012, at 5:52 AM, Rick Miller wrote: On Wed, Sep 26, 2012 at 4:19 PM, Devin Teske devin.te...@fisglobal.com wrote: All patched. http://svn.freebsd.org/changeset/base/240972 Can you test? I'll close the PR upon success. Success! Thanks! Excellent! Thank you for bringing this to my attention. -- Devin P.S. Closed PR (no releases to MFS) _ 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: FreeBSD 8.x sysisntall dists
-Original Message- From: vrwmil...@gmail.com [mailto:vrwmil...@gmail.com] On Behalf Of Rick Miller Sent: Wednesday, September 26, 2012 11:47 AM To: dte...@freebsd.org Cc: FreeBSD Questions Subject: Re: FreeBSD 8.x sysisntall dists dists=base kernels GENERIC SMP DEBUG doc catpages DEBUG was added to the above along with the new release build. All distributions get installed with the exception of DEBUG. In looking through sysinstall sources (I am not much of a C programmer to begin with) and it appears as though the sources need to be modified to support a new DEBUG distribution. I wonder if you might be able to confirm or refute this... Confirmed. I'll raise a PR with a patch to correct this. Awesome! Thanks for the quick reply, Devin! If you don't mind, will you pass on the PR so I can track it? Sure, no prob. It should appear in GNATS within 15-20 minutes. I'll get you the PR number when I get my response from GNATS. I am also considering approaching one of our developers to ask if they can write a patch, would that be helpful? No need. Patch is already written. I'll be submitting it to my mentor for review/approval shortly. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: FreeBSD 8.x sysisntall dists
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of dte...@freebsd.org Sent: Wednesday, September 26, 2012 1:10 PM To: 'Rick Miller'; dte...@freebsd.org Cc: 'FreeBSD Questions' Subject: RE: FreeBSD 8.x sysisntall dists -Original Message- From: vrwmil...@gmail.com [mailto:vrwmil...@gmail.com] On Behalf Of Rick Miller Sent: Wednesday, September 26, 2012 1:06 PM To: dte...@freebsd.org Cc: FreeBSD Questions Subject: Re: FreeBSD 8.x sysisntall dists Confirmed. I'll raise a PR with a patch to correct this. Awesome! Thanks for the quick reply, Devin! If you don't mind, will you pass on the PR so I can track it? Sure, no prob. It should appear in GNATS within 15-20 minutes. I'll get you the PR number when I get my response from GNATS. bin/172096: sysinstall does not support new DEBUG kernel distribution in 8.x I am also considering approaching one of our developers to ask if they can write a patch, would that be helpful? No need. Patch is already written. I'll be submitting it to my mentor for review/approval shortly. Submitted. Excellent, thanks! Patch was approved. PR should be closed within the hour. All patched. http://svn.freebsd.org/changeset/base/240972 Can you test? I'll close the PR upon success. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: bad root shell in /etc/passwd
On Sep 26, 2012, at 6:06 PM, Gary Aitken wrote: I mistakenly changed the root shell to something which doesn't exist. Was trying to make it bash and used /bin/bash instead of /usr/local/bin/bash. As a consequence, all login attempts fail because the shell can't be found. Unfortunatley, I shut down the session in which I modified /etc/passwd and I don't have a root shell running anywhere, so I can't fix it. I'm concerned that booting single user will have the same problem. Or will it fall back to /bin/sh? guidance? Single-user mode will prompt you. The default is /bin/sh but you can change it. You should be able to solve the problem by entering single-user mode. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Creating kernel distribution from sources
On Sep 24, 2012, at 6:03 AM, Rick Miller wrote:
Hi All,
I've generated a DVD iso and imported it into a provisioning platform.
After this integration, a decision was made to rebuild the kernel
with an option enabled. As opposed to executing a full `make
release`, I just want to build the kernel distribution. In reading
the manpage, it looks like I can just run `make release.3 make
release.5 make release.6` to accomplish this. Is this correct?
Would the resulting files be installed in ${CHROOTDIR}/R?
Almost! Don't forget you need to first remove the target files created by each
of those targets.
In example:
rm -f /usr/release/usr/obj/usr/src/release/release.{3,5,6}
make release.{3,5,6}
Yes, the resulting files will be in (by default) /usr/release/R
--
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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Install Problem
Not saying your suggestion won't work but… The last time I had to flip the SATA mode in a BIOS to Compatibility (sometimes labeled Legacy or IDE mode) was when I was installing FreeBSD-4.11 on an Intel S5000PSL/R. I don't think I've come across a machine that required me to change the SATA mode before installing FreeBSD 9. The OP may have said he tried sysinstall approaches but unless he specifically said he tried Druid, it actually implies he was comparing FreeBSD 8 media to FreeBSD 9's. This is naturally not a fair fight because both install media are using different kernels. That's why I recommend that you try a sysinstall based installer that's actually built from/for 9.0-RELEASE. It will boot with a 9.0 kernel and use sysinstall to automatically set up the system. Trying FreeBSD Druid will put the two installers (sysinstall v bsdinstall) on the same ground using the same kernel, so we'll be able to tell if its your hardware or the installer. -- Devin On Sep 7, 2012, at 11:46 PM, Dale Scott wrote: Check the SATA drive mode in the BIOS. It may need to be set to Compatibility (or vice versa). -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of dte...@freebsd.org Sent: Friday, September 07, 2012 6:20 PM To: 'Chris Neudorf'; questi...@freebsd.org Subject: RE: FreeBSD Install Problem -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Chris Neudorf Sent: Friday, September 07, 2012 2:10 PM To: questi...@freebsd.org Subject: FreeBSD Install Problem Hello, I have a problem installing FreeBSD 9.0 Releaseon my Lenovo Thinkpad R61i laptop (4GB RAM, 160GB HDD, 32-bit). It doesn't matter if I tried installing it from the CD or the DVD, I still have the same problem. I even tried re-downloading and re-burning a new CD or DVD, and I'm still unable to install. I even have problems going through the sysinstall route. Can you try the following? http://sourceforge.net/projects/druidbsd/files/FreeBSD-9.0_Druid-1.0b57.iso/ down load NOTE: New version posted just a couple days ago (but not announced yet; in-progress). -- Devin In the installation process, I'm able to go far to the partitioning area in where the problem occurs. I click for Guided partitioning and then I receive this Abort message: Abort -- An installation step has been aborted. Would you like to restart the installation or exit the installer? --- [ Restart ] [ Exit ] - When I click restart I end up with the same result, and I end up in a neverending cycle of unable to install. (I even have a the same problem installing from GhostBSD.) Is there any remedies to this problem? Thank you so much, --Christopher ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: can a jail have link to outside of the jail?
On Aug 16, 2012, at 11:51 AM, Len Conrad wrote:
I have an ssh user who needs only to search some log files not in his jail.
The jail required because I don't want the user seeing the rest the machine.
If the dirs were linked to his jail, would that work?
To show a directory from a base-host to a member-jail, I'd recommend using a
nullfs-mount.
Furthermore, you can automate the process in 2 different ways (scoped
differently depending on how you use jails).
You can add jail_{name}_mount_enable=YES to rc.conf(5) which enables the
automatic handling of /etc/fstab.{name} every time you perform a service jail
start|stop|restart {name} (the mount will automatically be mounted and
unmounted on-demand of bringing the jail up-and-down irrespective of the base
host but respective to each jail). You'd load you /etc/fstab.{name} with your
nullfs mounts.
The second way is of course is to put all your nullfs mounts into /etc/fstab
(proper) but mark them as noauto (if desired) and optionally (if going the
noauto approach) add jail_{name}_exec_prestart=mount dirname and likewise
[optional] jail_{name}_exec_poststop=umount dirname
All depending on how you use jails.
If you'd of course rather prefer all the mounts come up at boot and go from
permanent directories to permanent directories (which you know will never go
away), _and_ you like the idea of not having mounts going up and down with your
jails (perhaps you're fine-tuning your jail's startup), I'd say throw them into
/etc/fstab full-auto and not associate them with the jails. But it's all up to
you.
Hope that helps.
What I'd really like is something like ftpchroot for but ssh.
Hmmm, does the above approach work better? just exposing one directory to his
jail via nullfs?
suggestions?
--
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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Is there a way to run FreeBSD ports through port 80?
On Jul 12, 2012, at 9:23 AM, Kaya Saman wrote: Hi, I am trying to introduce FreeBSD into my office and it's been looked at with quite a bit of enthusiasm however, what makes it look bad is our companies 'security' policy to block FTP. At present they are running a whole bunch of CentOS based boxes and VM's which of course can be run through port 80 when using YUM. How does one get round this issue as my superiors are telling me that opening up FTP is a security risk and therefor don't want to proceed? I would like to use ports specifically and not the pkg_add tool to get software. Can anyone sugget anything? env ftp_proxy=host:port command where command is your normal command, such as fetch. For a full list of environment variables you can use,… $ ldd -f '%p\n' `which fetch` | xargs grep -alr ftp_proxy | xargs strings -n 7 | grep _proxy fetch_no_proxy_match fetch_default_proxy_port http_proxy ftp_proxy no_proxy -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Is there a way to run FreeBSD ports through port 80?
On Jul 12, 2012, at 9:42 AM, Kaya Saman wrote: On Thu, Jul 12, 2012 at 5:33 PM, Devin Teske devin.te...@fisglobal.com wrote: On Jul 12, 2012, at 9:23 AM, Kaya Saman wrote: Hi, I am trying to introduce FreeBSD into my office and it's been looked at with quite a bit of enthusiasm however, what makes it look bad is our companies 'security' policy to block FTP. At present they are running a whole bunch of CentOS based boxes and VM's which of course can be run through port 80 when using YUM. How does one get round this issue as my superiors are telling me that opening up FTP is a security risk and therefor don't want to proceed? I would like to use ports specifically and not the pkg_add tool to get software. Can anyone sugget anything? env ftp_proxy=host:port command where command is your normal command, such as fetch. For a full list of environment variables you can use,… $ ldd -f '%p\n' `which fetch` | xargs grep -alr ftp_proxy | xargs strings -n 7 | grep _proxy fetch_no_proxy_match fetch_default_proxy_port http_proxy ftp_proxy no_proxy -- 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. Thanks Devin for this however, setenv ftp_proxy ftp://ip:port indicates that FTP is being proxied out. We simply have it banned on a Juniper firewall. So http is being proxied by a web appliance but that's it... nothing else. Yep. It's up to your proxy server whether it's going to handle FTP or only HTTP (and/or HTTPS). I use squid a lot and it handles FTP great. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: binary diff utility
On Jun 29, 2012, at 8:53 AM, Wojciech Puchar wrote: i have many windows images running over virtualbox. each takes several gigabytes. i use flat image format. each differs by very little. Is there any program that can do diff and keep just a difference between each of them instead copy of whole VM disk?? Try libxdiff… http://www.freshports.org/textproc/libxdiff/ From the pkg-descr: The LibXDiff library implements basic and yet complete functionalities to create file differences/patches to both binary and text files. The library uses memory files as file abstraction to achieve both performance and portability. For binary files, LibXDiff implements (with some modification) the algorithm described in File System Support for Delta Compression by Joshua P. MacDonald, while for text files it follows directives described in An O(ND) Difference Algorithm and Its Variations by Eugene W. Myers. Memory files used by the library are basically a collection of buffers that store the file content. There are two different requirements for memory files when passed to diff/patch functions. Text files for diff/patch functions require that a single line do not have to spawn across two different memory file blocks. Binary diff/patch functions require memory files to be compact. A compact memory files is a file whose content is stored inside a single block. WWW: http://www.xmailserver.org/xdiff-lib.html -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: binary diff utility
On Jun 29, 2012, at 9:01 AM, Ariel Burbaickij wrote: Xdelta if I correctly understood what you want. vbindiff might also fit the bill… http://www.freshports.org/textproc/vbindiff/ From the pkg-descr: Visual Binary Diff (VBinDiff) displays files in hexadecimal and ASCII (or EBCDIC). It can also display two files at once, and highlight the differences between them. Unlike diff, it works well with large files (up to 4 GB). WWW: http://www.pobox.com/~cjm/vbindiff/ -- Devin /wbr Ariel Burbaickij On Fri, Jun 29, 2012 at 5:53 PM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: i have many windows images running over virtualbox. each takes several gigabytes. i use flat image format. each differs by very little. Is there any program that can do diff and keep just a difference between each of them instead copy of whole VM disk?? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: binary diff utility
On Jun 29, 2012, at 8:53 AM, Wojciech Puchar wrote: i have many windows images running over virtualbox. each takes several gigabytes. i use flat image format. each differs by very little. Is there any program that can do diff and keep just a difference between each of them instead copy of whole VM disk?? Der, someone over my shoulder highlights the fact that there's bsdiff and bspatch in the base system for diffing/patching binary files. But your mileage may vary with such large files. Something from ports that's already been recommended may work better. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: changing md5 hashed for sha
On Jun 23, 2012, at 6:37 AM, Christopher J. Ruwe wrote: For setting the dafault hash used to hash /etc/master.passwd, it has been recommended changing md5 for something more secure in the sense of being more expensive to crack. The handbook describes the procedure used in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/crypt.html. Allegedly, hashes which were hashed with one of the sha-functions begin with the character $6$. Unfortunately, it appears that login.conf is ignored by pw w/respect to group(5) passwords. Example Given: Setting passwd_format=blf in login.conf(5) followed by executing: echo newpass | sudo pw usermod SOMEUSER -h 0 sudo grep '^SOMEUSER:' /etc/master.passwd # shows Blowfish hash starting with $2a$, meanwhile… echo newpass | sudo pw groupmod SOMEGROUP -h 0 grep '^SOMEGROUP:' /etc/group # shows login.conf(5) was ignored and an old-style crypt password (2-letter salt; 8-character max password) :( -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: A bash scripting question
On Jun 21, 2012, at 6:40 AM, Odhiambo Washington wrote:
How Can I simplify/perfect the following script, so that I read _ALL_ the
lines in the file and act on the content as shown below, so that I do not
have to specifiy an action per line?
This below is doing exactly what i need BUT reading one line at a time
untill the 10th line, if i want more i add manually...
This might help some1 someday! But if there is a way to perfect it please
do so.
#!/usr/local/bin/bash
smsfile=email_to_sms
`grep Subject /var/spool/mail/sms $smsfile`
if [[ -s $smsfile ]] ; then
cat /dev/null /var/spool/mail/sms
sed -i 's/Subject: //g' $smsfile
echo `sed -n '1p' $smsfile` | /usr/bin/gammu --sendsms TEXT `awk 'NR==1
{print $1}' $smsfile`
echo `sed -n '2p' $smsfile` | /usr/bin/gammu --sendsms TEXT `awk 'NR==2
{print $1}' $smsfile`
echo `sed -n '3p' $smsfile` | /usr/bin/gammu --sendsms TEXT `awk 'NR==3
{print $1}' $smsfile`
echo `sed -n '4p' $smsfile` | /usr/bin/gammu --sendsms TEXT `awk 'NR==4
{print $1}' $smsfile`
echo `sed -n '5p' $smsfile` | /usr/bin/gammu --sendsms TEXT `awk 'NR==5
{print $1}' $smsfile`
echo `sed -n '6p' $smsfile` | /usr/bin/gammu --sendsms TEXT `awk 'NR==6
{print $1}' $smsfile`
echo `sed -n '7p' $smsfile` | /usr/bin/gammu --sendsms TEXT `awk 'NR==7
{print $1}' $smsfile`
echo `sed -n '8p' $smsfile` | /usr/bin/gammu --sendsms TEXT `awk 'NR==8
{print $1}' $smsfile`
echo `sed -n '9p' $smsfile` | /usr/bin/gammu --sendsms TEXT `awk 'NR==9
{print $1}' $smsfile`
echo `sed -n '10p' $smsfile` | /usr/bin/gammu --sendsms TEXT `awk 'NR==10
{print $1}' $smsfile`
else
echo ***Sorry the SMS FILE $smsfile is empty.
fi
gammu-smsd start
cat email_to_sms email_to_sms2
cat /dev/null email_to_sms
Try the following…
#!/bin/sh
smsfile=email_to_sms
spoolfile=/var/spol/mail/sms
grep Subject $spoolfile $smsfile
if [ -s $smsfile ]; then
: $spoolfile
sed -e 's/Subject: //g' $smsfile | awk '
{
if (NR 10) exit
print | /usr/bin/gammu --sendsms TEXT $1
}'
else
echo ***Sorry the SMS FILE $smsfile is empty.
fi
gammu-smsd start
cat $smsfile email_to_sms2
: $smsfile
--
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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: How do I determine support for $xx?
Hi Rick (!), On Jun 8, 2012, at 8:07 AM, Rick Miller wrote: Hi All, If this question is better suited for a different list please let me know. Simply stated, my question is 'What is the best source for identifying supported hardware?'. The source! Actually, pciconf and grep unknown /var/run/dmesg.boot and using pcidatabase.com are all good starts (for me at least). When I'm integrating new/old hardware there isn't one path that I take. It really depends on what the situation is. (and so to give you the best advice, I read-on) Having said that, allow me to pose an example... I've attempted to identify if various ethernet controllers are supported by FreeBSD and the drivers. I used the hardware notes and manpages for the respective ethernet drivers. The information between the two sometimes seems inconsistent and/or inaccurate. For example, the BCM5719 and BCM5720 are unsupported in FreeBSD at this time. That *was* true, but it's integrated quite well now with 8.3-R. We have a few NEC workstations eval's fresh for testing that are using that hardware. The hardware notes at freebsd.org do not specify these controllers are supported. Inspection of the bge(4) manpage implies that the controllers are supported as seen in the description section where it states: The bge driver provides support for various NICs based on the Broadcom BCM570x, 571x, 572x, 575x, 576x, 578x, 5776x and 5778x Gigabit Ethernet controller chips and the 590x and 5779x Fast Ethernet controller chips. I browsed the source and found many references to the BCM5719 and BCM5720. However, I am unfamiliar enough with driver programming in C to identify if a controller is fully supported. You really need to know the 4-digit hexadecimal Vendor ID and Model ID of the chipset to KNOW that a source module will probe/attach to a given hardware by-spec. Probing/attaching is mostly done by registry arrays defining these hex values as what to attach to during probe. Of course, booting the OS is the best way. If your HW device is not picked up by any module (built-in or otherwise), then you'll get a line like the following in /var/run/dmesg.boot: pci0: unknown card (vendor=0x1106, dev=0x3057) at 4.4 There's those hex values. If you take the device value and enter it into pcidatabase.com you'll get: http://pcidatabase.com/search.php?device_search_str=0x3057device_search=Search Which comes up as: ACPI Power Management Controller by VIA Technologies, Inc That's the unknown device. But, let's focus on BCM5720… If you were running, say, 8.0-R, even if you have the bge(4) driver loaded, you would see this in /var/run/dmesg.boot: pciN: unknown card (vendor=0x1106, dev=0x165f) at X.Y NOTE: Insert random numbers for N, and X.Y How you know that 8.3-R's bge(4) driver supports the BCM5720 is because this source file: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bgereg.h?annotate=1.83.2.35.2.1 NOTE: I specifically pointed you at CVS instead of SVN so that you can see the version tagged for 8.3-R Specifically, this line: 2309: #defineBCOM_DEVICEID_BCM5720 0x165F Also, I attempted to identify whether the Intel i350 is supported. It's not listed in the hardware notes or the igb(4) manpage so I suspect it is not supported. Boot up and see if it shows up as an unknown device. HINT: 0x8086 is often Intel's Vendor ID It's easier to start that route and get the vendor/device hex so you can recursively grep src/sys/dev for those hex values (make sure to do it case insensitively). Investigating each match (especially if it ends in _reg.h or _reg.c or hw.c etc.) should show you (in code) which modules may (or may not) support a given unknown hardware (either in your current branch or another). If you're commonly dealing with new hardware on an often-enough basis, then it's advisable to have a copy of HEAD checked out for keeping src/sys/dev up to date for recursive grepping to find out if hardware is supported (in the previously described manner). When I view the igb source, the i350 is referenced numerous times. Are these references simply code in preparation for support of the i350? Maybe. If you have HW specs for the board you're trying to integrate, check for the vendor/device id's and see if they match the references that you're finding in code. -- 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-questions@freebsd.org mailing list
Re: How do I determine support for $xx?
On Jun 8, 2012, at 9:45 AM, Devin Teske wrote:
Hi Rick (!),
On Jun 8, 2012, at 8:07 AM, Rick Miller wrote:
[snip]
I browsed the source and found many references to the BCM5719 and
BCM5720. However, I am unfamiliar enough with driver programming in C
to identify if a controller is fully supported.
[snip]
If you were running, say, 8.0-R, even if you have the bge(4) driver loaded,
you would see this in /var/run/dmesg.boot:
pciN: unknown card (vendor=0x1106, dev=0x165f) at X.Y
Correction, (specific to BCM5720) you'd see:
pciN: unknown card (vendor=0x14e4, dev=0x165f) at X.Y
Which, btw, you can confirm to yourself by executing the following within 8.3-R
(with attached bge(4)):
$ pciconf -lv | awk '/^bge/{print $1,$4}'
bge0@pciN:A:B:C: chip=0x165f14e4
Otherwise, you can see an unknown (non-working bge(4)) Broadcom BCM5720
hardware by executing (on 8.0-R for example):
$ grep unk /var/run/dmesg.boot | grep 0x14e4
pciN: unknown card (vendor=0x14e4, dev=0x165f) at X.Y
NOTE: On a system where all hardware is probed/attached, grep unk
/var/run/dmesg.boot should not produce any results. In this case, pciconf is
your tool for probing vendor/device IDs.
NOTE: Insert random numbers for N, and X.Y
How you know that 8.3-R's bge(4) driver supports the BCM5720 is because this
source file:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bgereg.h?annotate=1.83.2.35.2.1
NOTE: I specifically pointed you at CVS instead of SVN so that you can see
the version tagged for 8.3-R
Specifically, this line:
2309: #defineBCOM_DEVICEID_BCM5720 0x165F
[snip]
--
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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: hard link identification
On May 22, 2012, at 2:26 PM, Robert Bonomi wrote: dte...@freebsd.org wrote; For directories, the link-count is quite obviously the number of filesystem entities contained within. That is *INCORRECT*. Details. The OP wanted to know about files. I chose to not elaborate on the directory-case of the value (as it was not important to the OP). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: jail v2 documentation?
On Apr 14, 2012, at 2:19 PM, Mark Felder wrote:
On Sat, 14 Apr 2012 14:59:47 -0500, fb...@a1poweruser.com wrote:
I don't see any v2 in the jail environment. Vimage is a separate software
module that is not part of the the system base release. It has to be
compiled into a custom kernel to be enabled and it's labeled as
experimental, use at your own risk. Not some thing I would want in my jail
environment. So the bottom line is there is no version 2 of the jail
environment,(IE changes to the jail command and its associate commands).
Actual changes to the jail command can be found here:
http://lists.freebsd.org/pipermail/freebsd-jail/2011-July/001568.html
How to use the jails v2 is covered many places. It does indeed exist, and you
can probably use the package here to get yourself started because the rc.d
script for jails is not updated to handle v2 jails.
http://druidbsd.sourceforge.net/vimage.html
The .shtml that I added in the website re-design looks nicer ^_^
http://druidbsd.sourceforge.net/vimage.shtml
I'm also planning on updating it with nice and pretty netgraph drawings.
When you're using my vimage package, you can use the following command to
produce a nice diagram of your network:
sudo ngctl dot | dot -Tsvg -o $HOSTNAME-vimages.svg
Requires graphics/graphviz from ports/packages.
NOTE: I personally like SVG as it scales very nicely. Five command-line driven
X11 applications that can display SVG are graphics/gimmage, graphics/gthumb,
graphics/gqview, graphics/gx, and graphics/eog. Also, the latest version of
every browser (including Firefox10/11, Chrome13, Safari5, and IE9) can display
SVG. Latent versions of Operating Systems have built-in support as well
(including Mac OS X Lion and Windows 7).
Alternatively, you can generate PNG or JPG using one of:
sudo ngctl dot | dot -Tpng -o $HOSTNAME-vimages.png
sudo ngctl dot | dot -Tjpg -o $HOSTNAME-vimages.jpg
I've uploaded a PNG for viewing pleasure:
http://druidbsd.sourceforge.net/download/warden0.jbsd.svg
NOTE: If you really need JPG or PNG, graphics/ImageMagick has the convert
utility which is, well, almost magical in a sense (if not already hinted-at by
the name). ^_^
How to read the diagram:
The pink cluster at the top-right are unused interfaces. Unused in the
sense that netgraph doesn't have anything to do with them. In my graph for our
FreeBSD-8.1 server named warden0.jbsd.vicor.com (it runs jails, get it? haha;
and it's on the jbsd network, for jailed-bsd hosts).
In the diagram, igb1 is shown as unused (it's displayed in the pink
disconnected cluster -- which, if you're viewing in the browser, mousing over
the cluster will display cluster_disconnected as a reminder of its purpose).
This is not entirely true, it's in-use by the base-hose (warden0.jbsd). The
other unused item is the socket we used to dump the dot(1) graph (see
ng_socket(4) and ngctl(8)).
In the SVG diagram, there are a total of 5 vimage jails running on the host,
sharing one physical Ethernet port and one physical wire (flowing through the
igb0 interface). The five hosts are named (in rc.conf(5)):
kps0a_dev
kps64a_dev
kws82a_dev
kws411a_dev
kws411b_dev
All these hosts are using the same On-board Intel Gigabit (igb(4)) network
interface as illustrated in the above linked-to SVG image.
An ether-link is created for each vimage and hooked into a bridge that is
created for the specific hardware interface. An upper-link is then created
between the bridge and the hardware interface. Finally (for convenience) a
lower-link is created between the bridge and the hardware interface (allowing
the base host -- warden0.jbsd -- to interact with the vimages).
The links and their types are rendered in octagons and the netgraph objects are
rendered as records (multi-field boxes). At the bottom-left of each record (the
lower-left field) is the netgraph type. For example,
At the top-left of the graph you'll see a record where the top-field is
ng0_kps64a_dev: (explained below), the lower-left field is eiface, and the
lower-right field is [15]:, the eiface is the netgraph type.
For each of the netgraph types, such as eiface, ether, bridge, and
socket, you can say man ng_{type} (for exampe, man ng_bridge or man
ng_ether).
The aforementioned top-field of each record is the interface name visible by
ifconfig(8) inside the vimage. The format is ngNN_NAME where NN is the
number starting at zero for each bridged interface (regardless of which
underlying hardware interface is backing the netgraph(4)-created interface) and
NAME is the rc.conf(5) name of the vimage.
Here's another SVG showing a machine running 7 high-security vimages:
http://druidbsd.sourceforge.net/download/bastion.svg
We see something very different from this system. In this system, we're not
utilizing bridging versus simply shoving multiple network interfaces into
various vimages. In this case, each vimage is
Re: FreeBSD's backwards webdesign / corporate identity
On Apr 8, 2012, at 5:40 AM, Tony wrote: Hello! As much as I love FreeBSD, [snip] I propose a new, supersimple look for FreeBSD based on Helveticahttp://www.youtube.com/watch?v=wkoX0pEwSCw. [snip] Tony [snip] http://www.designcouncil.org.uk/ It's like a punch-line almost. I admit to enjoying the Helvetica Trailer video linked-to above. I even admit to liking the proposed motto's. But I disagree with any sentiment that designcouncil.org.uk embodies the same clean lines and well-thought-out design that is being encouraged here. Most egregious is the mishmash of serif with sans-serif and misaligned content areas. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: learning freebsd kernel
-Original Message-
From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-
questi...@freebsd.org] On Behalf Of gahn
Sent: Friday, April 06, 2012 11:05 AM
To: freebsd general questions
Subject: learning freebsd kernel
hi gurus:
how could i create the core dumps on freebsd kernel? i am trying to create a
kernel core dump on 8.1 but it didn't happen:
# sysctl -w debug.kdb.panic=1
well the system went panic, entered the mode db. i did reboot' but there was
no core/kernel dumps under /var/crash.
Did you set the dumpdev directive in /etc/rc.conf?
% grep dumpdev /etc/defaults/rc.conf
dumpdev=NO# Device name to crashdump to (or NO).
savecore_flags= # Used if dumpdev is enabled above, and present.
You should set the value of dumpdev to your swap device.
You can get this value by executing the following:
awk '$3~/swap/{print $1}' /etc/fstab
Should produce something like /dev/mfid0s1b or da0s1b or ada0s1b or
ad0s1b etc. depending on your RELEASE and hardware.
If the output is, for example, /dev/mfid0s1b, you should add the following to
/etc/rc.conf:
dumpdev=/dev/mfid0s1b
--
Devin
the customized kernel has those information enabled:
# Debugging for use in -current
options KDB # Enable kernel debugger support.
options DDB # Support DDB.
options GDB # Support remote GDB.
user@host:~:$ sysctl -a | grep debug.kdb
debug.kdb.stop_cpus: 1
debug.kdb.trap_code: 0
debug.kdb.trap: 0
debug.kdb.panic: 0
debug.kdb.enter: 0
debug.kdb.current: ddb
debug.kdb.available: ddb
by the way, where is my gdb? on one of my company's machisne, it looks like
this:
debug.kdb.available: ddb gdb
thank you all
/gahn
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: learning freebsd kernel
-Original Message-
From: gahn [mailto:ipfr...@yahoo.com]
Sent: Friday, April 06, 2012 1:02 PM
To: Devin Teske; 'freebsd general questions'
Subject: Re: learning freebsd kernel
thanks devin for the great tip. yeah, now i got core dumps...:)
but where is my gdb under that debug.kdb.available?
I'm not sure I understand the question.
debug.kdb.available shows ddb for me
I usually use kgdb(1) for examining kernel core files.
--
Devin
best
/gahn
- Original Message -
From: Devin Teske devin.te...@fisglobal.com
To: 'gahn' ipfr...@yahoo.com; 'freebsd general questions' freebsd-
questi...@freebsd.org
Cc:
Sent: Friday, April 6, 2012 2:13 PM
Subject: RE: learning freebsd kernel
-Original Message-
From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-
questi...@freebsd.org] On Behalf Of gahn
Sent: Friday, April 06, 2012 11:05 AM
To: freebsd general questions
Subject: learning freebsd kernel
hi gurus:
how could i create the core dumps on freebsd kernel? i am trying to create a
kernel core dump on 8.1 but it didn't happen:
# sysctl -w debug.kdb.panic=1
well the system went panic, entered the mode db. i did reboot' but there
was
no core/kernel dumps under /var/crash.
Did you set the dumpdev directive in /etc/rc.conf?
% grep dumpdev /etc/defaults/rc.conf
dumpdev=NO # Device name to crashdump to (or NO).
savecore_flags= # Used if dumpdev is enabled above, and present.
You should set the value of dumpdev to your swap device.
You can get this value by executing the following:
awk '$3~/swap/{print $1}' /etc/fstab
Should produce something like /dev/mfid0s1b or da0s1b or ada0s1b or
ad0s1b etc. depending on your RELEASE and hardware.
If the output is, for example, /dev/mfid0s1b, you should add the following
to
/etc/rc.conf:
dumpdev=/dev/mfid0s1b
--
Devin
the customized kernel has those information enabled:
# Debugging for use in -current
options KDB # Enable kernel debugger support.
options DDB # Support DDB.
options GDB # Support remote GDB.
user@host:~:$ sysctl -a | grep debug.kdb
debug.kdb.stop_cpus: 1
debug.kdb.trap_code: 0
debug.kdb.trap: 0
debug.kdb.panic: 0
debug.kdb.enter: 0
debug.kdb.current: ddb
debug.kdb.available: ddb
by the way, where is my gdb? on one of my company's machisne, it looks like
this:
debug.kdb.available: ddb gdb
thank you all
/gahn
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-
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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Remote System Builds
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Doug Hardie Sent: Monday, March 26, 2012 11:54 AM To: Martin McCormick Cc: freebsd-questions@freebsd.org Subject: Re: Remote System Builds On 26 March 2012, at 11:20, Martin McCormick wrote: Is there yet any way to remotely rebuild a FreeBSD system? I have two FreeBSD systems on two remote campuses that presently run FreeBSD6.3. They need to be running FreeBSD9.0 and I don't really care how I get there as long as it can be done over the network. If we were physically there, I would put a CDROM in and blow them away since it is such a large jump. I can have staff members there install CDROM's that were remastered to use the serial console, but I am hoping that maybe we are moving past this sort of logistics. I just tried to unpack the 9.0 image using tar which has worked in the past to let one modify loader.conf but I got a bunch of errors this time about files that couldn't be created so maybe this is not the recommended headless installation technique any longer. I am going to be facing the same issue in a few months. My experiences with the serial console are that it is great for correcting small issues, trying to use it for initial configuration is not going to be real easy. I would like to be able to build a custom CD for that specific machine that doesn't need any operator input. They just install it and boot the machine. It would need to format the disk and do the complete installation (base and uniquely configured ports etc.). Is that possible? Our company is facing a jump from FreeBSD-4.11 to FreeBSD-8.1 later this year (in a few months). The challenge is recognized as: 1. Upgrade 3,000+ systems in a matter of 60-90 days. 2. Many of those systems need to be upgraded remotely where no technical staff exists (e.g. India, Philippines, Canada, etc.) 3. The remote upgrade must be done via SSH and NFS 4. Machines being upgraded must reboot and come back onto the network without local technical assistance The technique that I developed to accomplish this is a shell script weighing in at [currently] 1954 lines of code. In addition to the 1954 lines of code, there are another 631 lines of code dedicated to specific migrations that have to be performed specific to (say) jumping from 4.11 to 8.1 (e.g., you should remove the nodev option from your NFS mounts in /etc/fstab, among other things). On top of THAT, there's another 8778 lines of code dedicated to cruft removal (lists of files/directories that are unique to either the source-binary distro or the destination-binary distro; depending on the direction of migration). I will be releasing the full script soon (in a couple weeks) and even though it's not specifically targeted to your migration path (6.3 to 9.0), it can be learning-tool to illustrate exactly HOW you can go about making that binary migration a reality. Fortunately, it's very easy for me to provide explicit instructions on how exactly we jump from 4.11 to 8.1, or 8.1 back to 4.11, or even from 8.1 i386 to 8.1 amd64 (and back) ... the script that I've written takes a -nv syntax which means don't actually do anything, but show me the explicit commands that I can execute by-hand to migrate from one OS to the next as an in-place migration which has the following output: NOTE: The output below is a sample migration from 4.11 to 8.1-amd64 WARNING: This is not intended to be a full solution provided to the OP but rather a conversation-starter that should illustrate not only how HARD and/or DIFFICULT it is to do what the OP asked, but also to show how it IS POSSIBLE to achieve. WARNING: Also, it's worth noting that this procedure will NOT work to jump to 9.x because the binary distribution sets from 9.0 and higher are in a different format. You can work around this by adjusting for this fact -- replacing syntax such as cat base/base.?? | tar ... to simply cat base.txz | tar ... (accounting for the new monolithic distribution-sets in 9.0 and higher). === BEGIN OUTPUT OF OUR BINARY MIGRATION SCRIPT BELOW === Rebuild / with repository 8.1-RELEASE-amd64 TEST-ONLY! No actions will be performed. Source 8.1-RELEASE-amd64 specific config file . ./etc/8.1-RELEASE-amd64.conf Run 8.1-RELEASE-amd64 specific pre_install pre_install # Preflight sanity check (check release) #Migration from 4.11-STABLE to 8.1-RELEASE-amd64 allowed # Prevent disappearance of tar(1) rm -Rfv /var/db/pkg/tar-1.5 # Move `/usr/local/etc/rc.d' to `/usr/local/etc/rc.d.xbak-2012-03-26.12:32:08' mv -v /usr/local/etc/rc.d /usr/local/etc/rc.d.xbak-2012-03-26.12:32:08 mkdir -pv /usr/local/etc/rc.d chmod -v 0755 /usr/local/etc/rc.d chown -v root:wheel /usr/local/etc/rc.d Find/Remove core-dumps to free-up disk space find -x / -maxdepth 2 -name '*.core' -type f | xargs rm -fv
Re: Intercepting X11 events
On Mar 25, 2012, at 8:04 AM, Da Rock wrote: I'm not 100% sure where else to ask this. I have an annoying window that disappears when I click close (ha ha, yes I know it will usually do that, but this one doesn't go away) but it is unable to cooperate with the system tray so it simply becomes invisible, and hangs about in the background. In my investigationings I had a brainwave that since I cannot change the program (not without enormous effort) in the short term, maybe I can find a way to terminate the program and manage it externally with a script. So I'm looking to find a wrapper, or a script that can intercept the close event and kill the process (can't find a better way to handle it). Any ideas? I think you want x11/xnee from the ports tree. http://www.freshports.org/x11/xnee/ (blurb) … Xnee receives X11 protocol data (e.g. XEvents) from an X server and prints them to a file (or stout)… I'd think you'd be able to watch for the particular Event you're interested in. Another think you may want to look into is Full disclosure: Haven't used Xnee yet, but it has been on my radar as something cool to look into for awhile now. -- Devin The DE is lightweight (Icewm, LXDE, similar) so the tray is either non existent or incompatible; the app itself is (#%$!) java. Yep, thats right - it only speaks Gnome/KDE... Cheers Afterword: And yes, it took me that long to figure out the Java systray problem and the lack of a solution in my googling. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Intercepting X11 events
On Mar 25, 2012, at 10:26 AM, Devin Teske wrote: On Mar 25, 2012, at 8:04 AM, Da Rock wrote: I'm not 100% sure where else to ask this. I have an annoying window that disappears when I click close (ha ha, yes I know it will usually do that, but this one doesn't go away) but it is unable to cooperate with the system tray so it simply becomes invisible, and hangs about in the background. In my investigationings I had a brainwave that since I cannot change the program (not without enormous effort) in the short term, maybe I can find a way to terminate the program and manage it externally with a script. So I'm looking to find a wrapper, or a script that can intercept the close event and kill the process (can't find a better way to handle it). Any ideas? I think you want x11/xnee from the ports tree. http://www.freshports.org/x11/xnee/ (blurb) … Xnee receives X11 protocol data (e.g. XEvents) from an X server and prints them to a file (or stout)… I'd think you'd be able to watch for the particular Event you're interested in. Another think you may want to look into is Sorry, had a whole list of cool X11 ports (like xpra, xmx, and xwatchwin), but they didn't fit what you're looking for. No, I think x11/xnee is what you're looking for. -- Devin Full disclosure: Haven't used Xnee yet, but it has been on my radar as something cool to look into for awhile now. -- Devin The DE is lightweight (Icewm, LXDE, similar) so the tray is either non existent or incompatible; the app itself is (#%$!) java. Yep, thats right - it only speaks Gnome/KDE... Cheers Afterword: And yes, it took me that long to figure out the Java systray problem and the lack of a solution in my googling. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: GIMP(1) don't run
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Xavier FreeBSD questions Sent: Tuesday, March 20, 2012 10:06 AM To: freebsd-questions@freebsd.org Subject: GIMP(1) don't run Hi to all, When I want run GIMP(1) it say: gimp Shared object libpcre.so.0 not found, required by gimp How I can solvent this problem ? sudo pkg_add -r pcre -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
tar(1) and --uid/--gid on 9.0-RELEASE
I see in the tar(1) man-page on FreeBSD 9.0-RELEASE two options that I would like to use: --uid # --gid # Naturally, these are used to override the on-disk credentials while creating (or extracting) an archive. Problem? They don't seem to be supported. % tar cf some_archive.tar --gid 0 --uid 0 somedir tar: Option --gid is not supported ... WTF?! -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: New iso format on 9.0
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of jb Sent: Tuesday, February 21, 2012 9:53 AM To: freebsd-questions@freebsd.org Subject: Re: New iso format on 9.0 egoitz at ramattack.net writes: Good morning, Previously I was doing a : 'tar -C /expert/netboot/freebsd8 -pxvf 8.0-RELEASE-amd64-disc1.iso' for extracting iso files. ... There is a simple way to access contents of an iso file: # mount -o loop some.iso /mnt That works on FreeBSD? I commonly use that (daily even) on Linux, but was not aware that would work on FreeBSD. Here's the method I use on [modern] FreeBSD: mdconfig -a -t vnode -u 99 -f $ISOFILE mount -t cd9660 /dev/md99 /mnt And here's the method I would use on LEGACY FreeBSD: cd /dev sh MAKEDEV vn99 vnconfig -c vn99 $ISOFILE mount -t cd9660 /dev/vn99c /mnt Or, you can just download this script which works on both Linux and FreeBSD: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/src/tools/mou nt_iso.sh?view=log Usage: ./mount_iso.sh $ISOFILE /mnt Don't forget that when you're done, you have to deconfigure the device... On [modern] FreeBSD: umount /mnt mdconfig -d -u 99 And here's the method for LEGACY FreeBSD: umount /mnt vnconfig -u vn99c Or, you can just download this script which works on both Linux and FreeBSD: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/src/tools/umo unt_iso.sh?view=log Usage: ./umount_iso.sh /mnt -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: New iso format on 9.0
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of ego...@ramattack.net Sent: Tuesday, February 21, 2012 10:14 AM To: freebsd-questions@freebsd.org Subject: RE: New iso format on 9.0 umount /mnt vnconfig -u vn99c Or, you can just download this script which works on both Linux and FreeBSD: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/src/tools/ umo unt_iso.sh?view=log Usage: ./umount_iso.sh /mnt Hello all, And thanks a lot really for you're answers. Yes... I know the way you can mount an iso image (I have done a couple of times yesterday in fact)... but I'm really worried about how making a consistent copy of it like I did with tar... as I said this is for an unattended installation system... so I cannot be depending on having the cd mounted on the operating system... with tar the -p option was important for preserving permissions, flags, and so... perhaps now... should mount like you said before for example and later having an rsync compiled with file flag preserving support do an rsync -av /cd-mount-point /disk-place-to-copy-cd-content ?? this last is the real question... I have played previously several times with memory disks mappings, mdconfig and those staff but how to make a consistent copy of the cd for the unattended installation system... Why can't you mount the disc on /mnt and then use tar after mounting the disk to copy the files from /mnt to /destdir ... tar cpf - -C /mnt . | tar xvpf - -C /destdir That will preserve hard links, symlinks, permissions, and times (and doesn't require rsync). There are other methods involving cpio, but I find tar to be nice. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: One or Four?
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Jerry McAllister Sent: Saturday, February 18, 2012 1:34 PM To: Damien Fleuriot Cc: freebsd-questions@freebsd.org Subject: Re: One or Four? On Sat, Feb 18, 2012 at 12:07:30PM +0100, Damien Fleuriot wrote: On 2/17/12 11:05 PM, Robison, Dave wrote: Hiya, [snip] We realize that one can use bsdinstall to create as many partitions as one wants. However, the new default is for one partition and swap. We want to know if people would prefer the older style default with four partitions and swap when selecting Guided Partitioning and Use Entire Disk. Let the majority decide which layout is preferred for the default. Thanks, Dave Seeing as people using the default are likely to be novices, I vote in favor of ONE. The reasoning being that novices are less likely to be able to correctly size their /usr and /var than a seasoned sysadmin. So, we have now had scads of 'discussion' about schemes for disk partitioning and there were a bunch, plus arguments about which is the best with each person convinced that theirs is. As far as I can see, this all leads to the conclusion that the one design that gives a reasonable and simple set of choices for all fits the FreeBSD model that of providing a well made system and allowing the user/sysadmin to configure it the way [s]he wants/needs rather than imposing a common usage on everyone. Next we'll be arguing about which windows manager is mandatory for users to include at install time. So, Polytropon's three choice pattern is good. Or, I could even suggest just two choices. [ ] all in one + swap Create one partition containing all subtrees plus one swap partition. [ ] user-defined Make your own partitioning selection manually. (Both number and size of partitions) with a reasonable way to specify partitions and sizes. The old Sysinstall way is not bad, but if it obsolete, then something as easy that fits the new GPT based system. But, that middle choice that Polytropon suggested is OK to include if you think it is needed. /, /tmp, /usr, /var, [/home] +swap Choosing the 2 option scheme which removes the legacy option in my mind is not an option. It's 3 option scheme (which includes the server/legacy option) or revert back to the legacy scheme (period). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: One or Four?
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Chuck Swiger Sent: Friday, February 17, 2012 2:18 PM To: david.robi...@fisglobal.com Cc: freebsd-questions@freebsd.org Subject: Re: One or Four? On Feb 17, 2012, at 2:05 PM, Robison, Dave wrote: We'd like a show of hands to see if folks prefer the old style default with 4 partitions and swap, or the newer iteration with 1 partition and swap. For a user/desktop machine, I prefer one root partition. For other roles like a server, I prefer multiple partitions which have been sized for the intended usage. Then does the question ultimately become... Shall we then have two algorithms and ask the user whether they are installing for the desktop versus server? If that's the case, then I think this is something I could personally live with (as it then becomes possible to obtain the old layout of 4 partitions with auto-calculated sizes ala Colin Percival's last sizing algorithm committed in version 1.149 of src/usr.sbin/sysinstall/label.c made pre-SVN 6 years 6 months ago). See http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/sysinstall/Attic/label.c?rev= 1.149;content-type=text%2Fx-cvsweb-markup The above link describes the partition scheme that I and colleagues seek-most to return to FreeBSD 9.x and higher. I argue that Colin's algorithm is still useful for servers and is still the preferred method of allocation for servers and thus should remain an option, even if we don't change the [new] default back to the above linked-to scheme. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: One or Four?
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Jerry McAllister Sent: Friday, February 17, 2012 2:53 PM To: Polytropon Cc: david.robi...@fisglobal.com; freebsd-questions@freebsd.org Subject: Re: One or Four? Let the majority decide which layout is preferred for the default. Why not add a selection to the installer, something like this: Partition scheme [ ] all in one + swap Create one partition containing all subtrees plus one swap partition. [ ] separate partitioning + swap Create /, /var, /tmp and /usr (including home) partitions plus one swap partition. [ ] user-defined Make your own partitioning selection manually. Of course, the default SIZES for second choice should be reasonable. Yes. Yes. This is the way to go. I'd agree, but I'd like to envision a modular approach where multiple schemes can be maintained. E.g. a menu containing... Scheme 1: / + swap + /tmp Scheme 2: / + swap + /tmp + /var Scheme 3: / + swap + /tmp + /var + /usr Scheme 4: / + swap + /tmp + /var + /usr + /home NOTE: See what I did there? There is no option for / , explanation below. I'm actually thinking that not having a separate /tmp is: a. A security issue /tmp is by-default out-of-the-box world-writable (perms 1777). Making this world-writable bucket part of / seems silly both for Desktops and Servers alike. b. A nuisance As Da Rock points out, ... recovering your system from a file-system-full-event when using single-/ is just as difficult regardless of Desktop versus Server. Having /tmp alleviates the difficulty. c. A performance issue I'm surprised nobody has pointed out the physical performance limitations of rotating disks with respect to physical location of partitions on the spindle. Granted, seek times are light years beyond what they used to be, but allocating smaller swap and tmp partitions close to the center of the spindle is a performance-enhancing setup just as much as it is for protecting against file-system-full problems (security events included). === I'd argue that there should never be a single-/ unless you are prepared to deal with a truly 100%-full filesystem problem (especially considering that Desktop users whom select the default-everything are often not skilled enough to deal with that situation). If someone truly wants a single / and nothing else, there's manual partitioning (which should prove pretty easy in the event that you're only creating one partition and nothing else). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: One or Four?
-Original Message- From: Chuck Swiger [mailto:cswi...@mac.com] Sent: Friday, February 17, 2012 3:56 PM To: Devin Teske Cc: FreeBSD - Subject: Re: One or Four? On Feb 17, 2012, at 3:11 PM, Devin Teske wrote: a. A security issue /tmp is by-default out-of-the-box world-writable (perms 1777). Yes. It works as intended even when /tmp is part of a single root partition; although mounting /tmp as a RAM- or swap-based tmpfs filesystem might be better for many situations. Making this world-writable bucket part of / seems silly both for Desktops and Servers alike. You're welcome to your opinion. However, I suspect you're expecting FreeBSD systems to always be partitioned and administered by knowledgeable BSD Unix sysadmins, and those are not always so readily available as one might assume. b. A nuisance As Da Rock points out, ... recovering your system from a file-system-full-event when using single-/ is just as difficult regardless of Desktop versus Server. Having /tmp alleviates the difficulty. It would if /tmp was mounted on a disk partition, and if it also happened to be where space was being consumed. Actually, what I meant to say was: If you have only single-/ and your filesystem becomes full, having a separate /tmp on the same physical medium can alleviate the issue of having no space to work because you can mount /tmp (as the odds of both / and /tmp filling up simultaneously and both becoming 100%-full is far-less likely to occur than having a single partition fill up to max all). Thus, having a / + /tmp is infinitely wiser than single-/ without /tmp (or any partition for that matter). The argument not necessarily being in favor of /tmp, but being dis-favorable against any scheme that involves only one partition which can blindly be filled and leave the user (at least in a single-disk scenario) no free space to do anything once-full. This is somewhat different than what you were referring to, which is that having /tmp simply for the sake of not allowing others to fill your system. Rather, I'm arguing that /tmp also saves you by giving you somewhere to work if/when you *DO* fill your /. /var/log and /home tend to be more likely locations in my experience, but YMMV. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: One or Four?
-Original Message- From: Chuck Swiger [mailto:cswi...@mac.com] Sent: Friday, February 17, 2012 3:56 PM To: Devin Teske Cc: FreeBSD - Subject: Re: One or Four? On Feb 17, 2012, at 3:11 PM, Devin Teske wrote: [snip] I'd argue that there should never be a single-/ unless you are prepared to deal with a truly 100%-full filesystem problem (especially considering that Desktop users whom select the default-everything are often not skilled enough to deal with that situation). If someone truly wants a single / and nothing else, there's manual partitioning (which should prove pretty easy in the event that you're only creating one partition and nothing else). More sophisticated partition schemes certainly can have value in terms of better isolation from unexpected logfile growth (etc), a separation of OS-provided files from user content, a separation of stuff which doesn't change often versus stuff that does, and so forth. However, for whatever reasons, the overwhelming majority of folks using MacOS X don't have problems using a single root partition, and while they sometimes do fill up their disks, that's a situation which they should be able to recover from without needing expert assistance. I don't recall having unusual issues in running a partition out of space under FreeBSD, either, or difficulty fixing things afterwards-- Recipe for disaster: 1. You have a cron-job that pulls down /etc/master.passwd daily 2. Your cron-job also runs pwd_mkdb after SUPing down /etc/master.passwd 3. A program fills / 4. cron fires 5. pwd_mkdb can't generate databases because not enough room on filesystem 6. System can no longer be logged into 7. System is rebooted 8. Can't log in (not even as root) 9. Go into single-user mode 10. No space to work in Sure... you can call it an edge-case, but it's pretty common and this is only one of a myriad of ways we can reproduce the problem of filling-up / to cause major headaches. For example, let's say you don't have a cron-job that runs pwd_mkdb etc. Let's say you're just blissfully unaware of your disk space (or lack thereof) and you execute vipw. Exiting the program after making changes invokes pwd_mkdb and if there isn't enough disk space to accommodate the database, you're hosed. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: swap space
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Robison, Dave Sent: Friday, February 17, 2012 4:11 PM To: freebsd-questions@freebsd.org Subject: Re: swap space On 02/17/2012 15:58, Chuck Swiger wrote: On Feb 17, 2012, at 3:54 PM, Jim Pazarena wrote: is there a command which can show the size of the hard drive swap? A df seems to avoid the swap area. You're looking for swapinfo Regards, Chuck beat me to it. swapinfo or top are the two ways I normally check. I'm digging the fact that it now accepts -h to produce human-readable sizes. swapinfo didn't always support -h -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: One or Four?
-Original Message- From: Chuck Swiger [mailto:cswi...@mac.com] Sent: Friday, February 17, 2012 4:41 PM To: Devin Teske Cc: 'FreeBSD -' Subject: Re: One or Four? On Feb 17, 2012, at 4:11 PM, Devin Teske wrote: However, for whatever reasons, the overwhelming majority of folks using MacOS X don't have problems using a single root partition, and while they sometimes do fill up their disks, that's a situation which they should be able to recover from without needing expert assistance. I don't recall having unusual issues in running a partition out of space under FreeBSD, either, or difficulty fixing things afterwards-- Recipe for disaster: 1. You have a cron-job that pulls down /etc/master.passwd daily 2. Your cron-job also runs pwd_mkdb after SUPing down /etc/master.passwd Yes, I agree that this is a recipe for disaster; the reasons not very correlated to disk space, however. Even twenty years ago, handling this via YP/NIS or NetInfo would have made more sense, and nowadays folks would be far more likely to use LDAP as the network user database, instead of pushing system password database changes via SUP or similar replication mechanism locally to individual hosts. 3. A program fills / 4. cron fires 5. pwd_mkdb can't generate databases because not enough room on filesystem 6. System can no longer be logged into #5 does not imply #6: if pwd_mkdb can't build a temporary version to /etc/pwd.db.tmp /etc/spwd.db.tmp, it will exit with an error rather than invoke rename(2) to replace the working version of the password database with something that might be broken. Ok, then this is a departure from versions of yester-year. Glad to know that a temporary DB is built rather than rebuilding on-top of the existing DB (which last I checked 4.11 still does). To be very specific, I would expect one to get: /: write failed, filesystem is full pwd_mkdb: /etc/pwd.db to /etc/pwd.db.tmp: No space left on device Yeah, 4.11 wasn't so nice. 7. System is rebooted 8. Can't log in (not even as root) 9. Go into single-user mode 10. No space to work in Sure... you can call it an edge-case, but it's pretty common and this is only one of a myriad of ways we can reproduce the problem of filling-up / to cause major headaches. I've never heard of such a thing happening to a real FreeBSD system in the past decade or more. Only only needs to go back to 4.11 for this time-bomb (which still bites us at least once every 6-12 months in production -- mind you we still employ about 3,000 4.x systems and are migrating to 8.x this year). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: One or Four?
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Da Rock Sent: Friday, February 17, 2012 4:55 PM To: freebsd-questions@freebsd.org Subject: Re: One or Four? On 02/18/12 10:40, Chuck Swiger wrote: On Feb 17, 2012, at 4:11 PM, Devin Teske wrote: However, for whatever reasons, the overwhelming majority of folks using MacOS X don't have problems using a single root partition, and while they sometimes do fill up their disks, that's a situation which they should be able to recover from without needing expert assistance. I don't recall having unusual issues in running a partition out of space under FreeBSD, either, or difficulty fixing things afterwards-- Recipe for disaster: 1. You have a cron-job that pulls down /etc/master.passwd daily 2. Your cron-job also runs pwd_mkdb after SUPing down /etc/master.passwd Yes, I agree that this is a recipe for disaster; the reasons not very correlated to disk space, however. Even twenty years ago, handling this via YP/NIS or NetInfo would have made more sense, and nowadays folks would be far more likely to use LDAP as the network user database, instead of pushing system password database changes via SUP or similar replication mechanism locally to individual hosts. 3. A program fills / 4. cron fires 5. pwd_mkdb can't generate databases because not enough room on filesystem 6. System can no longer be logged into #5 does not imply #6: if pwd_mkdb can't build a temporary version to /etc/pwd.db.tmp /etc/spwd.db.tmp, it will exit with an error rather than invoke rename(2) to replace the working version of the password database with something that might be broken. To be very specific, I would expect one to get: /: write failed, filesystem is full pwd_mkdb: /etc/pwd.db to /etc/pwd.db.tmp: No space left on device 7. System is rebooted 8. Can't log in (not even as root) 9. Go into single-user mode 10. No space to work in Sure... you can call it an edge-case, but it's pretty common and this is only one of a myriad of ways we can reproduce the problem of filling-up / to cause major headaches. I've never heard of such a thing happening to a real FreeBSD system in the past decade or more. The closest match to the issue results in a failure of adduser(8) or pw(8) to add new users, but existing users continued to work fine. These are edge cases that _do_ happen - Linux (heaven forbid!) is reknown for the all /, and I've been unable to boot properly into it with a full disk. I had to use a live disk to rescue it which took hours thanks to the $%^! lvm filesystem. Its just so easy to run a multi partition as opposed to an all /. And how much does it cost/hurt to do it (especially given the inordinately large hdd's these days)? Next to nix (pardon the pun :) ). The reduction in problems for new users should be an incentive as well. +1 I imagine an increased load on -questions@ for users that need extra hand-holding when they fill their entire disks versus incidentally filling a single partition. One requires instructions involving a live disc versus the latter which involves dinking with a still-very-usable system. Time-to-recover is inordinately skewed between the two situations, 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: One or Four?
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Da Rock Sent: Friday, February 17, 2012 5:00 PM To: freebsd-questions@freebsd.org Subject: Re: One or Four? On 02/18/12 10:55, Da Rock wrote: On 02/18/12 10:40, Chuck Swiger wrote: On Feb 17, 2012, at 4:11 PM, Devin Teske wrote: However, for whatever reasons, the overwhelming majority of folks using MacOS X don't have problems using a single root partition, and while they sometimes do fill up their disks, that's a situation which they should be able to recover from without needing expert assistance. I don't recall having unusual issues in running a partition out of space under FreeBSD, either, or difficulty fixing things afterwards-- Recipe for disaster: 1. You have a cron-job that pulls down /etc/master.passwd daily 2. Your cron-job also runs pwd_mkdb after SUPing down /etc/master.passwd Yes, I agree that this is a recipe for disaster; the reasons not very correlated to disk space, however. Even twenty years ago, handling this via YP/NIS or NetInfo would have made more sense, and nowadays folks would be far more likely to use LDAP as the network user database, instead of pushing system password database changes via SUP or similar replication mechanism locally to individual hosts. 3. A program fills / 4. cron fires 5. pwd_mkdb can't generate databases because not enough room on filesystem 6. System can no longer be logged into #5 does not imply #6: if pwd_mkdb can't build a temporary version to /etc/pwd.db.tmp /etc/spwd.db.tmp, it will exit with an error rather than invoke rename(2) to replace the working version of the password database with something that might be broken. To be very specific, I would expect one to get: /: write failed, filesystem is full pwd_mkdb: /etc/pwd.db to /etc/pwd.db.tmp: No space left on device 7. System is rebooted 8. Can't log in (not even as root) 9. Go into single-user mode 10. No space to work in Sure... you can call it an edge-case, but it's pretty common and this is only one of a myriad of ways we can reproduce the problem of filling-up / to cause major headaches. I've never heard of such a thing happening to a real FreeBSD system in the past decade or more. The closest match to the issue results in a failure of adduser(8) or pw(8) to add new users, but existing users continued to work fine. These are edge cases that _do_ happen - Linux (heaven forbid!) is reknown for the all /, and I've been unable to boot properly into it with a full disk. I had to use a live disk to rescue it which took hours thanks to the $%^! lvm filesystem. Its just so easy to run a multi partition as opposed to an all /. And how much does it cost/hurt to do it (especially given the inordinately large hdd's these days)? Next to nix (pardon the pun :) ). The reduction in problems for new users should be an incentive as well. As for how quickly a disk can fill - I'm an expert :) I can fill a terabyte disk in a matter of hours with video and not notice. The transfers can be tricky to coordinate seeing as the disk fills faster than I can move the large files to another filesystem. And I haven't even mentioned some of the games that I'm sure a novice desktop user will use... You don't have to necessarily 'hose' the system to render it unusable. Just have some obscure program or service that requires something like a temp file or the like to stop it from working, and make it difficult to find whats wrong. I forgot to mention that the probable reason you haven't heard of any such problems on real FreeBSD _is_ because it doesn't use the all /, or a qualified sysadmin is watching over it. +1 And as ideal as it is to sit and hypothesize how great things might be in the Desktop world if Desktop users are given the chance to use one big / partition, I'm just terribly afraid (as you likewise point out) that the decision to make this the default was short-sighted to say the least. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: /dev/ulpt0 -- How is it created?
-Original Message-
From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-
questi...@freebsd.org] On Behalf Of Ronald F. Guilmette
Sent: Wednesday, February 08, 2012 1:58 PM
To: freebsd-questions@freebsd.org
Subject: /dev/ulpt0 -- How is it created?
It would appear that the device node /dev/ulpt0 gets (re-)created every
time I plug my USB printer back in.
Could somebody please kindly tell me what the exact mechanism is that
causes this device node to be (re-)created upon such events?
I am rather hoping that whatever that mechanism is, that I can diddle
it somehow so that every time /dev/ulpt0 gets created, it will be
created with perms set to 0666.
This should do the trick (as root):
mkdir -p /etc/devd
cd /etc/devd
touch ulpt.conf
cat ulpt.conf EOF
notify 100 {
match systemDEVFS;
match subsystem CDEV;
match cdev ulpt[0-9];
match type CREATE;
action /bin/chmod 666 /dev/$cdev;
};
EOF
service devd restart
--
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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD custom CD and extra files to be included in the iso
On Feb 4, 2012, at 1:37 AM, Amitabh Kant wrote: On Sat, Feb 4, 2012 at 2:50 PM, Amitabh Kant amitabhk...@gmail.com wrote: I have been able to use the make release command to create a custom iso for FreeBSD which includes some changes to the various bsdinstall scripts. It all works well as the iso / memory stick images / ftp files are generated and usable. What I would now like to do is try adding couple of files, scripts and/or packages, to this custom iso. I am a little confused on where the files should be placed so that it is placed in either root's home directory after installation? Amitabh Sorry for not making it clear in my last mail, I am using FreeBSD 9.0 RELEASE on amd64 arch. If you use the DRUID (http://druidbsd.sf.net/), this is extremely easy. Step-by-step instructions... NOTE: Feel free to use ANY operating system you like, so long as it has (1) /bin/sh (2) cvs (3) mkisofs (4) GNU make. Including (but not limited to) Mac OS X (with developer tools installed), Cygwin, Linux, and of course, FreeBSD. 1. mkdir druidbsd.sf.net 2. cd druidbsd.sf.net 3. cvs -d:pserver:anonym...@druidbsd.cvs.sourceforge.net:/cvsroot/druidbsd login NOTE: Press ENTER when prompted for CVS password: NOTE: Ignore warning about failed to open ~/.cvspass 4. cvs -z3 -d:pserver:anonym...@druidbsd.cvs.sourceforge.net:/cvsroot/druidbsd co -P druidbsd/druid NOTE: The screen will stream information for about 5-10 minutes as it downloads 510MB of source code to the FreeBSD DRUID installer -- a sysinstall(8) based custom FreeBSD 9.0 installer capable of installing *either* i386 or amd64 from the same disc (among many many other things). 5. cd druidbsd/druid NOTE: The DRUID has a special directory in-which anything placed there gets copied to the target installation disk automatically after installation of the Operating System completes (but before any post-installation scripts are run). This directory is called sys_custom and it lives within the RELEASE directory. Within sys_custom, files are copied exactly as-is, so since you mentioned that you wanted to copy files to /root, let's operate under that assumption below. 6. mkdir -p src/freebsd/repos/9.0-RELEASE-amd64/sys_custom/root 7. cp myfiles src/freebsd/repos/9.0-RELEASE-amd64/sys_custom/root/ NOTE: If you want the same files available for the installation of the i386 release of 9.0-RELEASE, you should repeat the above steps 6-7 with the destination directory src/freebsd/repos/9.0-RELEASE/sys_custom/root (remember, the DRUID is a unified installer that supports both the installation of i386 and amd64 from the same disc). 8. ./configure 9. make freebsd NOTE: Replace make with gmake if on FreeBSD NOTE: If you're using FreeBSD, you may have to first say pkg_add -r gmake followed by rehash (if using csh or tcsh as your shell). NOTE: Also, if you need to get mkisofs, it's pkg_add -r cdrtools (and again, rehash if using csh or tcsh as your shell). 10. You now have a custom FreeBSD_Druid-9.0b56.iso that will install your custom files automatically to /root when either i386 or amd64 is installed. ASIDE: sys_custom is like a dumping ground for anything and everything you simply want to be copied to-disk post-installation of the OS. If instead you want to write scripts to be run as part of the post-installation process, see instead dep/freebsd/run_once/template.sh and src/freebsd/repos/9.0-RELEASE/run_once/*.sh and src/freebsd/repos/9.0-RELEASE-amd64/run_once/*.sh. The run_once directory unlike sys_custom is a dumping ground for post-installation scripts (any script ending in .sh in that directory will automatically be executed as part of the post-installation procedure after installing the OS. ASIDE: As you can tell, the DRUID is a FreeBSD installer that was designed to be *easily* extended by anybody/everybody on any OS they like (any OS that can produce or edit an ISO that is). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Jails V2, VIMAGE, and integration in the base system
On Feb 4, 2012, at 10:45 AM, Hugo Silva wrote: On 02/03/12 17:02, Devin Teske wrote: Please give this a try: http://druidbsd.sf.net/vimage.shtml http://druidbsd.sf.net/download.shtml Hi, Interesting. Is it safe to run in production (VIMAGE/vnets) ? I can't speak to every application, release, or even purpose, but we've been using between 2 and 3 dozen vimages for various purposes without problem on 8.1-RELEASE-p6 (just haven't got around to updating to -p7 which is lated RELENG_8_1 security patch). We've been running amd64 hosts with both amd64 and i386 jails. Doing compiler builds, using them as web servers, shell servers, bastion's, gateways, proxies (both shell and web), and even for running legacy releases of FreeBSD (running 4.11 i386 on an amd64 8.1 host). So the VIMAGE/vnets support seems pretty stable in 8.1-RELEASE. Oh, we did have to MFC SVN r207194 to fix a bug in sys/net/rtsock.c when running i386 route(8) in VIMAGE under amd64 host. Though you don't have to apply the patch, as the workaround was simple -- copy the host's amd64 route(8) over vimage's i386 one. That's really the only bug we ever hit, but your mileage may vary. We've been generally very happy with VIMAGE/vnets so far. Now, with respect to the script being production ready, I'd say yes with one minor nit... Unnecessarily starting/stopping vimages after boot is bad for two reasons: 1. In 8.1-RELEASE there's an necessary loss in VM pages everytime you remove a vimage jail with jail -r (this has been fixed in later releases). 2. The Ethernet HW address auto-calculations performed in my script are based on the order in which vimages are started and stopped. This is easily overcome by setting the HW address in the ifconfig_* line within rc.conf(5) (within the vimage rootdir). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Jails V2, VIMAGE, and integration in the base system
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Hugo Silva Sent: Friday, February 03, 2012 8:17 AM To: freebsd-questions@freebsd.org Subject: Jails V2, VIMAGE, and integration in the base system Hello, I didn't find much about jails v2 + epair + vimage on google; The FreeBSD wiki pages concerning this subject seem fairly outdated (that or not much has happened in 3 years), and the manpages don't mention much about vimage/vnet. According to http://ivoras.net/freebsd/freebsd8.html it should be in FreeBSD 8.0 (VIMAGE, Jails v2), and maybe it is, but if it's not integrated in the base system and information/documentarion is scarse, few will use it. Found this: http://www.freebsd.org/cgi/query-pr.cgi?pr=142972 - nearly 2 years old. My question is, how wise would it be to attempt to use these features in production? IMO this is very interesting stuff, having these things integrated would be a worthy addition to FreeBSD. Please give this a try: http://druidbsd.sf.net/vimage.shtml http://druidbsd.sf.net/download.shtml -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
[ANN] FreeBSD Druid 9.0b56
Behold! FreeBSD Druid! http://druidbsd.sourceforge.net/ Install FreeBSD 9.0 with sysinstall (!!) -- Devin NOTE: This is beta 56 of the Druid platform in-general (and thus the version 9.0b56) but it does NOT install a beta version of FreeBSD. Rather, it installs FreeBSD 9.0-RELEASE (32 or 64-bit, your choice). P.S. A note to ADVANCED users... if you're going to skip the scripted installation for any reason -- dropping to traditional sysinstall procedure -- then to utilize the on-disc RELEASE, select as your medium Directory and enter either (1) /cdrom/freebsd/repos/9.0-RELEASE or (2) /cdrom/freebsd/repos/9.0-RELEASE-amd64. This is not intuitive and one may be tempted to select CD-ROM as the media type, but this is incorrect. P.P.S. There is much more written at the newly-updated website. You'll want to hit these URLs for this software... http://druidbsd.sourceforge.net/ http://druidbsd.sourceforge.net/download.shtml http://druidbsd.sourceforge.net/freebsd_druid.shtml https://sourceforge.net/projects/druidbsd/files/ _ 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
+ Re: 9.0 install problems
On Jan 28, 2012, at 1:30 PM, Henry Olyer henry.ol...@gmail.com wrote: When I boot the CD I get a different menu, ie., boot, shell, install. Since the CD is in the CD-ROM drawer and I know how to use sysinstall (or so I thought!,) I get a fresh shell and say sysinstall. Okay? Except I can't write the disk. Notice, I have not explicitly mounted it or done anything to reserve it. I need a procedure to do this please. It's just a small machine. But having this up let's me do a backup and once I've backed up the disks on my other computers, then I can do some serious stuff with 9.0. I'd like to use sysinstall, if possible. I know it and I like it. The answer is here (as-in arrived): http://druidbsd.sf.net/ http://druidbsd.sf.net/freebsd_druid.shtml -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Portability of shell scripts from other *nixes
On Jan 25, 2012, at 8:13 PM, Chuck Swiger wrote:
Hi--
On Jan 25, 2012, at 7:24 PM, Da Rock wrote:
On 01/26/12 12:55, Doug Poland wrote:
This gets me closer, but the scripts behave differently now on OS X. For
example, printf's don't output the same.
Try searching on google and find out exactly what sh MacOSX is using. Then
you'd have a better idea on what you're working with.
/bin/sh on MacOSX is:
$ /bin/sh --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
Copyright (C) 2007 Free Software Foundation, Inc.
...and it has been using bash as /bin/sh since 10.2 or so.
Anyway, running bash as /bin/sh versus as /bin/bash likely affects whether it
invokes printf as a builtin(1) command or as an external command. It's
possible that invoking /usr/bin/printf instead of just printf in the scripts
might resolve the issue(s).
If that's the problem, perhaps a trick can do:
printf(){builtin printf $@;}
At the top after the she-bang. Should cause all invocations to use built-in
versus otherwise by defining a function that explicitly calls the built-in.
--
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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: kgzip(8) regression in RELENG_9 GENERIC
On Jan 23, 2012, at 12:56 AM, CyberLeo Kitsana wrote: On 01/23/2012 12:30 AM, Devin Teske wrote: On Jan 21, 2012, at 1:41 AM, CyberLeo Kitsana wrote: On 01/20/2012 09:02 PM, Devin Teske wrote: Taking a GENERIC 9.0-RELEASE kernel and running kgzip(8) on it produces an unusable kernel which causes immediate BTX halt in loader(8). ... 4. Say: kgzip kernel Curious, it doesn't even look like that binary is hooked into the build process at all on 9.0-RELEASE. Can you clarify what you mean by the above? On a brand new GENERIC box running 9.0-RELEASE with no special knobs: 8 (4b18d544)[cyberleo@jenga ~]$ which kgzip On my box: push900# uname -a FreeBSD push900.vicor.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 push900# which kgzip /usr/sbin/kgzip (4b18d544)[cyberleo@jenga ~]$ apropos kgzip push900# whereis kgzip kgzip: /usr/sbin/kgzip /usr/share/man/man8/kgzip.8.gz /usr/src/usr.sbin/kgzip (4b18d544)[cyberleo@jenga ~]$ cd /usr/src/usr.sbin (4b18d544)[cyberleo@jenga /usr/src/usr.sbin]$ ls | grep kgzip kgzip (4b18d544)[cyberleo@jenga /usr/src/usr.sbin]$ grep kgzip Makefile (4b18d544)[cyberleo@jenga /usr/src/usr.sbin]$ 8 push900# grep kgzip Makefile # $FreeBSD: release/9.0.0/usr.sbin/kgzip/Makefile 116221 2003-06-11 21:36:06Z obrien $ PROG= kgzip MAN=kgzip.8 SRCS= kgzip.c aouthdr.c elfhdr.c kgzcmp.c kgzld.c xio.c So it's there, Yes, there it is. How is it that my GENERIC 9.0-RELEASE build has it, source included, manual included, Makefile included, binary included,... but yours does not? but the SUBDIR entry in the usr.sbin Makefile that hooks it into the build process seems to be missing, whereas things that do exist (freebsd-update, c) are present. It's manpage indicates that it is unsuitable for loader(8) use, Likewise, can you clarify the above? From kgzip.8 in the aforementioned directory: 8 BUGS As symbols are lost, the usefulness of this utility for compressing ker- nels is limited to situations where loader(8) cannot be used; otherwise the preferred method of compressing a kernel is simply to gzip(1) it. 8 That's an odd sort of message. I've been using kgzip(1) since the days of RELENG_4 ... with loader(8) mind you, and have never had a problem until now with RELENG_9. and that just running gzip(1) on the kernel file is sufficient; I'm getting an error when loading a gzip(1)'d kernel... don't know how to load module '/kernels/GENERIC-i386-9.0.gz' So I figure, maybe it doesn't like the '.gz' suffix. No go, same error. I think we'll need more information on how your system is set up to boot: First, it's not my system, it's my installer. I'm taking on the task of creating a dual-installer (pictures linked-to below): http://www.twitpic.com/89l2ub/full http://www.twitpic.com/89l4n6/full I usually use kgzip'd kernels on my installer. It's always worked in the past (period). The reason for doing so is that it takes a 14MB GENERIC kernel and reduces it to 4.6MB (pretty obvious incentive there). partition layout, None to speak of. All I'm really doing to replicate the BTX halt is loading up an ISO with the following contents: 1. loader(8) from unmodified RELENG_9 2. kgzip(1)'d kernel -- again, unmodified RELENG_9 (GENERIC) 3. load kernel with FICL ``load'' 4. boot 5. BTX halted immediately what boot blocks and loaders are in use, etc. All from 9.0-RELEASE How are you instructing it to load that particular kernel, for example? Here's the FICL syntax used which replicates the BTX halt: load /kernels/GENERIC-i386-9.0.kgz load -t mfs_root /boot/fis_mfsroot9.gz set vfs.root.mountfrom=ufs:/dev/md0 set vfs.root.mountfrom.options=rw boot This leads to BTX halt. Simply going in and swapping kgzip(1)'d kernel for non-kgzip(1)'d kernel fixes the problem. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Horrible installer (was: Re: FreeBSD 9)
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Wojciech Puchar Sent: Monday, January 23, 2012 10:25 AM To: Damien Fleuriot Cc: freebsd-questions@freebsd.org Subject: Re: Horrible installer (was: Re: FreeBSD 9) Allan ___ Erm, you have to realize the new installer was discussed at length here, when 9.0 was still under development/beta/prerelease. Alternatively, you could do like me and install entirely by hand: - boot an MFSBSD image (thanks mm@ ) - partition your disks from there (see http://my.gd/bsd.htm for a rough sketch on how to use gpart) - fetch the 9.0 archives in .txz (tar.xz) format - unpack archives with xz -d - untar archived to the mountpoint with your new filesystems (eg: tar xf base.tar -C /mnt) - customize configuration files (rc.conf, fstab, root's password or SSH key, sshd_config to allow root login temporarily) and almost like me installing previous release (FreeBSD 8) everywhere. i just made once bootable pendrive with system, lots of tools and whole system as .tar.gz files (made my own compiling from cvs) actually i add WITHOUT_SYSINSTALL=yes to make.conf so i don't build it at all. And IMHO sysinstall should not exist, while good documentation about installing BY HAND should be there. Someone that cannot install it him/herself will not be able to ever manage it after so why waste time. Disagree. For example, field engineers which may not be expected to know how to manage FreeBSD _ARE_ expected to know how to install it. A manual install process is more prone to errors than one that is guided by something/anything. Do not forget that FreeBSD is for unix users, Not all users are people. A corporation can be considered a unix user which changes the perspective quite a bit. contrary to linux which is for windoze haters. Again i propose removing sysinstall altogether. And you'll have your wish... over time! The community has agreed to phase out sysinstall(8) gradually over the next 2 or three releases (producing either a 10.0 or 11.0 that is free of sysinstall depending on how things progress with respect to replacement utilities such as bsdinstall and the proposed bsdconfig). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
* Re: Clang - what is the story?
On Jan 22, 2012, at 6:38 AM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Da Rock freebsd-questi...@herveybayaustralia.com.au wrote: I personally had no idea this was going on; my impression was gcc grew out of the original compiler that built unix, and the only choices were borland and gcc. The former for win32 crap and the latter for, well, everything else. Once upon a time, there were _many_ alternatives for C compilers. Commercial -- i.e. 'you pay for it', or bundled with a pay O/S -- offerings included (this is a _partial_ list, ones _I_ have personal knowledge of): PCC -- (the original one0 medium-lousy code but the code-generator was easily adapted to new/diferent hardwre Green Hills Softwaware (used by a number of unix hardare manufacturers) Sun Microsystems developed their own (acc) Silicon Graphics, Inc Hewlett-Packard Symantic (Think C -- notable for high-performance on early Apple Mac's, significantly better than Apple's own MPW) Ah, MPW... I knew ye well. But don't forget Metrowerks CodeWarrior Though, I preferred the finicky-ways of MPW (requiring explicit headers) to the fast-and-loose ways of MCW. -- Devin Manx Software (Aztec C -- a 'best of breed' for MS-DOS) Microsoft Intel CCS Watcom Borland Zortech Greenleaf Software Ellis Computing (specializing in 'budget' compilers, circa $30 pricetags) Small C tcc -- the 'tiny C compiler I'm sure others can name ones I've overlooked. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: kgzip(8) regression in RELENG_9 GENERIC
On Jan 21, 2012, at 1:41 AM, CyberLeo Kitsana wrote: On 01/20/2012 09:02 PM, Devin Teske wrote: Taking a GENERIC 9.0-RELEASE kernel and running kgzip(8) on it produces an unusable kernel which causes immediate BTX halt in loader(8). ... 4. Say: kgzip kernel Curious, it doesn't even look like that binary is hooked into the build process at all on 9.0-RELEASE. Can you clarify what you mean by the above? It's manpage indicates that it is unsuitable for loader(8) use, Likewise, can you clarify the above? and that just running gzip(1) on the kernel file is sufficient; I'm getting an error when loading a gzip(1)'d kernel... don't know how to load module '/kernels/GENERIC-i386-9.0.gz' So I figure, maybe it doesn't like the '.gz' suffix. No go, same error. Or maybe there's a special syntax to loading a gzip'd kernel? If so, that's unfortunate as no special syntax is required to execute kgzip'd kernels. Also, kgzip produces smaller binaries than gzip when used on kernel. I'd like to see kgzip(1) functionality restored (again, it worked fine in RELENG_8). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
kgzip(8) regression in RELENG_9 GENERIC
Taking a GENERIC 9.0-RELEASE kernel and running kgzip(8) on it produces an unusable kernel which causes immediate BTX halt in loader(8). NOTE: This is w.r.t. a completely un-modified src-tree (including the GENERIC config itself). Just thought I'd share this regression. 8.1-RELEASE-p6 doesn't have this problem. To replicate (warning DO NOT DO THIS unless you know how to recover the boot process using either interactive loader(8) or LiveCD): 1. Install i386 9.0-RELEASE and make sure you select that you wish to unpack src.txz 2. Go to /usr/src/sys/i386/compile and say: config -C -g GENERIC 3. Go to ../compile/GENERIC and say: make cleandepend make depend make 4. Say: kgzip kernel 5. Copy kernel.kgz to /boot 6. Add kernel=kernel.kgz to loader.conf(5) 7. Reboot 8. Witness your own death via BTX halted -- Devin NOTE: Looking for confirmation from at least one other individual before filing a PR on this one. It could be any number of factors and not a true regression. For example, I'm using VMware Workstation 7.1 to replicate this. _ 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
* Re: Horrible installer
Sent from my iPhone On Jan 20, 2012, at 7:43 PM, gore koggy...@comcast.net wrote: [snip] I also bought the newer 4th Edition when it came out. (Having Marshal Kirk McKusick do the forward made me happy, he's one of my personal heros. I also got to speak with him recently and I was almost speechless I LOVE that guy, and he's so funny! The DVD 25 years of Bereley Unix is something I'd recommend you ALL buy. I also loved how nice he was. Marshal Kirk McKusick is one of the nicest, friendliest people I've have the pleasure of talking to). [snip] why not just use 8.x or something? I'm not being sarcastic or anything either, I really am asking why not jut go to 8.2 which I also Loved? SU+J by Kirk McKusick ?? :-D -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
* Re: FreeBSD 9
On Jan 19, 2012, at 1:05 AM, inquiz inq...@gmx.com wrote: Allan McKinnon mckinnon at live.com writes: ... I really enjoyed the old installer because then I had complete control over how I tweaked my computer during and after the install. I agree. The new installer got rid of dependencies and is scriptable - very good ! ??? *cough* Old installer _is_ scriptable and had less external dependencies as it was written in C not sh(1) *cough* -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: * Re: FreeBSD 9
On Jan 19, 2012, at 7:20 AM, inquiz wrote: Devin Teske devin.teske at fisglobal.com writes: ... The new installer got rid of dependencies and is scriptable - very good ! ??? *cough* Old installer _is_ scriptable and had less external dependencies as it was written in C not sh(1) *cough* Well, here it is: http://wiki.freebsd.org/BSDInstall Right, but those claims (1 - being scriptable and 2 - not requiring utilities outside the base) are *both* not unique to bsdinstall and its predecessor (sysinstall) exhibited both those features long before bsdinstall. We've been scripting sysinstall since 2006. Successfully, I might add (and yes, we plan to release a 9.0 scripted sysinstall image to share the love). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 9
On Jan 19, 2012, at 8:46 AM, Chad Perrin wrote: On Thu, Jan 19, 2012 at 10:41:37AM +, inquiz wrote: Eduardo Morras nec556 at retena.com writes: ... I think that a full/complete update of the old installer to add it support GEOM, ZFS, scripting and more newer features will consume more manpower and resources than create a new one from scratch, where the devs aren't chained by old code, backwards compatibility, old restrictions and old point of views. This way, is easier correct bugs, new features, simplify the installation and even automate it to this new installer than try to add them to the old one. As always, i suppose that any ideas and help are welcome. ... If devs decided that there are good technical and other reasons to retire the old installer, then that's fair enough. But then the new installer has to be at least equal in features, functionality, and overall quality. . . . or provide the ability to select the old installer at boot time, perhaps. Let's not turn this into a false dilemma; I don't see why we can't have our cake and eat it too for a while. Before sysinstall is simply made available as an option, it first needs to be taught how to handle a monolithic txz file because the structure of the system has changed. Also... sysinstall expects to boot into a RW filesystem, and I don't know yet whether the architecture has changed in this respect. If bsdinstall doesn't boot into an MFS, then having the boot loader set vfs.root.mountfrom.options to rw is of little effect (for example, if you're booting directly into an ISO 9660 filesystem which can't be made writable -- unionfs aside). So, whatever prompt the user is given to choose between sysinstall and bsdinstall... said prompt best be pretty early in the game (if we're going to fork to two different operating environments: MFS versus ISO 9660). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: FreeBSD 9
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Chad Perrin Sent: Thursday, January 19, 2012 8:43 AM To: freebsd-questions@freebsd.org Subject: Re: FreeBSD 9 On Thu, Jan 19, 2012 at 11:15:08AM +0100, Eduardo Morras wrote: I think that a full/complete update of the old installer to add it support GEOM, ZFS, scripting and more newer features will consume more manpower and resources than create a new one from scratch, where the devs aren't chained by old code, backwards compatibility, old restrictions and old point of views. This way, is easier correct bugs, new features, simplify the installation and even automate it to this new installer than try to add them to the old one. I'm curious: Is this just speculation, or have you determined this by reading the source of the old installer? Old code means *tested* code, and when it is well- maintained it often means easily extensible code. Is that the case for the old installer, or is the older installer a crufty mess of temporary fixes that became permanent, as your statements seem to imply? I believe the difficulty in maintenance stems primarily from the fact that the existing partition editor MAY have to be entirely rewritten to accommodate other root filesystem types (but even that's not entirely true -- if done right). Other than that, it's most likely just FUD and misperception that sysinstall(8) is either (a) hard to maintain or (b) hard to extend. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: FreeBSD 9
-Original Message- From: Frank Shute [mailto:fr...@shute.org.uk] Sent: Thursday, January 19, 2012 12:01 PM To: Devin Teske Cc: 'Chad Perrin'; freebsd-questions@freebsd.org Subject: Re: FreeBSD 9 On Thu, Jan 19, 2012 at 11:22:14AM -0800, Devin Teske wrote: On Thu, Jan 19, 2012 at 11:15:08AM +0100, Eduardo Morras wrote: I think that a full/complete update of the old installer to add it support GEOM, ZFS, scripting and more newer features will consume more manpower and resources than create a new one from scratch, where the devs aren't chained by old code, backwards compatibility, old restrictions and old point of views. This way, is easier correct bugs, new features, simplify the installation and even automate it to this new installer than try to add them to the old one. I'm curious: Is this just speculation, or have you determined this by reading the source of the old installer? Old code means *tested* code, and when it is well- maintained it often means easily extensible code. Is that the case for the old installer, or is the older installer a crufty mess of temporary fixes that became permanent, as your statements seem to imply? I believe the difficulty in maintenance stems primarily from the fact that the existing partition editor MAY have to be entirely rewritten to accommodate other root filesystem types (but even that's not entirely true -- if done right). Other than that, it's most likely just FUD and misperception that sysinstall(8) is either (a) hard to maintain or (b) hard to extend. -- Devin To quote the manpage for sysinstall: BUGS snip This utility is a prototype which lasted several years past its expira- tion date and is greatly in need of death. There are a (great) number of undocumented variables. UTSL. Perspective. Let's take a look at the commit history for this manual. Try as you might, you can't go back far-enough to find when that message was even added. However, you can see where the message was tweaked slightly by a couple people: SVN r49961 by mpp@ addressing PR docs/13148 and docs/13144 Prior to-which the message said 3 years past (s/3/several/) SVN r40275 by jkh@ (no PR mentioned) Prior to-which the message said 2 years past (s/2/3/) So, literally for the past 15+ years, the man-page has said essentially the same thing prototype ... in need of death. I raise the hypothesis that: a. The prototype ... in need of death message in the man-page was added by the original author, whom... b. ...had self-esteem issues on that particular day (hence the self-denigrating remark about one's code). I further pontificate that once the original author relinquished control of sysinstall(8) (whomever that may be -- since commit logs don't go back that far) that one of the 2-dozen-plus committers should have removed that message to quell evident propagation of FUD against sysinstall(8)). Afterall, who's to say that sysinstall(8) was still a prototype when it was being used for several major releases in production and enterprise environments. But instead, this entry in the man-page was not removed, year-after-year, but instead maintained (with no apparent rhyme or reason). The situation is the exact opposite of what we're seeing with bsdinstall. sysinstall(8) was added to the tree as a prototype yet was stable. Now we see bsdinstall added to the tree as a NON-prototype yet is NOT-stable or free of show-stoppers! I welcome the new installer. sysinstall was a piece of buggy garbage that gave a pretty poor first impression of FreeBSD. I think we have some very different opinions of what buggy is. The new installer will get better with time. The new installer is buggy, and the above maxim is something I'd rather not have to deal with when downloading RELEASE software. RELEASE software shouldn't be released under the statement it will get better with time. Releasing feature-INcomplete software that is known to be broken hurts the FreeBSD impression far more than sysinstall ever could/did. I feel your argument is an attempt to justify the egregious offense of foisting premature software on the community when in-fact it does NOT replicate even a fraction of the abilities of sysinstall. 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions
RE: FreeBSD 9
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Chad Perrin Sent: Thursday, January 19, 2012 3:15 PM To: freebsd-questions@freebsd.org Subject: Re: FreeBSD 9 On Thu, Jan 19, 2012 at 02:36:29PM -0800, Devin Teske wrote: From: Frank Shute The new installer will get better with time. The new installer is buggy, and the above maxim is something I'd rather not have to deal with when downloading RELEASE software. I do not dispute that the new installer is buggy, nor do I agree that it is buggy. It surely has numerous usability problems. a. SHIFT+TAB is interpreted as ESC causing a dialog to be dismissed with no easy way to return to said dialog b. TAB does not move the cursor to the next field in a multi-field dialog such as IPv4 manual configuration (usability issue arises when you press TAB, nothing happens, you next try ENTER and are surprised null fields are accepted/not-validated and you're then whisked off to the next screen; again, no easy way to return to said dialog despite the fact that clearly bad-values were given for netmask/etc.) c. stderr is sent to the same console as stdout, making it impossible to read errors as they get printed and then subsequently wiped from screen by the next dialog (this ties into the above... the bad values provided cause errors which can't be seen; you only see them fly by for a micro-second and can't use Scroll-lock to view them as dialog wiped the buffer). d. Almost no user-provided values are taint-checked. A hostname for example does not need to conform to any of the given RFCs that dictate the format of a multi-label FQHN. e. bsdinstall provides no easy way of discovering which arguments it supports (other than looking in /usr/libexec/bsdinstall -- which if you don't know this, you're in the dark). That is to say that it has no -h, no --help, no list, and no exploration mode. This usability issue is fueling threads that propose we remove any/all post-installation procedures from bsdinstall and move them to a new utility called bsdconfig which provides a master-list of all sub-modules that can be invoked (as this closer matches how config utilities are utilized versus install utilities). It really is a serious usability issue that bsdinstall without arguments does not have an execution path that can lead to re-obtaining the network configuration dialog (which you've presumably bombed-out-of due to one of the previously-mentioned usability issues). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: FreeBSD 9
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Chad Perrin Sent: Thursday, January 19, 2012 3:15 PM To: freebsd-questions@freebsd.org Subject: Re: FreeBSD 9 On Thu, Jan 19, 2012 at 02:36:29PM -0800, Devin Teske wrote: From: Frank Shute The new installer will get better with time. The new installer is buggy, and the above maxim is something I'd rather not have to deal with when downloading RELEASE software. [snip] If the reason it was decided to create bsdinstall and replace sysinstall was simply to do something new The way we view the timeline of events is: 1. FreeBSD in the beginning had one official filesystem -- UFS1 -- for the root filesystem. 2. FreeBSD gets a new filesystem -- UFS2. sysinstall(8) is updated to support this as the new ONLY offering (though you can still get a UFS1 partition by pressing Z to set a custom value for newfs arguments, if you're in-the-know). 3. Enterprise FreeBSD community then desperately wants journaling filesystem, but ZFS is the only offering with built-in journaling (gjournal does not qualify here) as McKusick's SU+J is not ready yet. 4. Community recognizes that sysinstall(8) needs to be updated but can't envision a successful re-work of the C-code that provides the FDISK Partition Editor screen to the point where it can handle both the UFS options as well as ZFS, etc. 5. Nathan Whitehorn envisions bsdinstall to solve the problem. However, we feel that something went wrong along the way. If FreeBSD had decided that there is no need to offer ZFS-on-root and instead put their eggs in the SU+J basket, then modifying sysinstall(8) to meet the needs of supporting SU+J would have been trivial at-best as all options would be UFS based. Hypothetically, once you landed in the FDISK Partition Editor of sysinstall(8), the auto partitioning would default to UFS2 SU+J and you could toggle any combination of SU+J, SU-J, and no-SU/J. In fact, this is still a possibility. sysinstall(8) could be enhanced to support SU+J and the people that don't care about ZFS-on-root can be happy with the sysinstall(8) route as it still leads to a journaled filesystem. Meanwhile, if they want ZFS-on-root, they'll have to go to the bsdinstall route. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: FreeBSD 9
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Devin Teske Sent: Thursday, January 19, 2012 4:33 PM To: 'Chad Perrin'; freebsd-questions@freebsd.org Cc: Dave Robison Subject: RE: FreeBSD 9 [snip] If FreeBSD had decided that there is no need to offer ZFS-on-root and instead put their eggs in the SU+J basket, then modifying sysinstall(8) to meet the needs of supporting SU+J would have been trivial at-best as all options would be UFS based. Well, not entirely true. sysinstall(8) would need to be re-worked to support GPT versus MBR. Otherwise system is limited to 2TB on root filesystem (lol; as if that were a limit we were concerned with -- I've not seen a whole lot of setups that required 2TB for the root filesystem). -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: FreeBSD 9
-Original Message-
From: 'Frank Shute' [mailto:fr...@shute.org.uk]
Sent: Thursday, January 19, 2012 4:52 PM
To: Devin Teske
Cc: 'Chad Perrin'; freebsd-questions@freebsd.org; Dave Robison
Subject: Re: FreeBSD 9
On Thu, Jan 19, 2012 at 02:36:29PM -0800, Devin Teske wrote:
I believe the difficulty in maintenance stems primarily from the
fact that the existing partition editor MAY have to be entirely
rewritten to accommodate other root filesystem types (but even
that's not entirely true -- if done right).
Other than that, it's most likely just FUD and misperception that
sysinstall(8) is either (a) hard to maintain or (b) hard to
extend. -- Devin
To quote the manpage for sysinstall:
BUGS
snip
This utility is a prototype which lasted several years past
its expira- tion date and is greatly in need of death.
There are a (great) number of undocumented variables. UTSL.
Perspective.
Let's take a look at the commit history for this manual.
Let's not. Let us discuss the merit of what the manpage says.
There are a (great) number of undocumented variables.
From my reading of postings to this list and stable@,
yet not -sysinstall@ (?!)
it was felt that sysinstall
couldn't be extended without a total re-write, that seems to suggest that the
manpage is right and is not FUD.
I disagree. Just because you document something doesn't make it true.
I've already discussed the fact that the first line you quoted (in need of
death) is 15+ years old and we have no way of tracking its origin and thus
can't extrapolate why on-Earth it was put into a release-quality product in
the first place.
The second line you quote (which was added 2 years 10 months ago via SVN r189754
by grog@) has everything to do with highlighting the fact that sysinstall(8) is
highly scriptable through a large number of under-documented dispatch keywords
and nothing to do with the total re-write issue you're discussing.
Plus, the keywords are a lot more documented than you think. If a dispatch word
is not documented, there's probably good cause (a great number of the dispatch
keywords are meant for internal use only and their documentation would merely
invite strangeness only reserved for people that know what they're doing -- i.e.
they can read the code to learn what their function is).
However, I will concede to the fact that the number of dispatch keywords that
are documented versus ones that CAN be used is only about 33%.
Here's how I generated that number...
awk '/VAR_/{sub(/[^]*/,);sub(/$/,);print}'
/usr/src/usr.sbin/sysinstall/sysinstall.h | sh -c 'while read var;do zgrep -q
\$var\ /usr/share/man/man8/sysinstall.8.gz
varcount=$((${varcount:-0}+1));done;echo $varcount'
This returns the number of variables -- as-defined-as a dispatch keyword in
sysinstall.h -- are present in the manual.
In 9.0-RELEASE, it returns 33 for me.
In contrast with the number of dispatch keywords, obtainable by:
awk '/VAR_/{print}' | wc -l
which returns 105 for me ... minus the markedly internal keywords which begin
with _...
awk '/VAR_/{print}' | grep -vc '_'
We see 101 supposedly-usable dispatch keywords which brings us to about 33%
documentation.
However, I will re-iterate...
The first quote you pulled from the man-page was made 15+ years ago, the second
quote you pulled was from 2+ years ago and the two are not related. The first
declares some inferred quality about the code itself and the second simply
states that the variable keywords are under-documented. One not-necessarily
imply the other or vice-versa.
--
Devin
Try as you might, you can't go back far-enough to find when that
message was even added. However, you can see where the message was
tweaked slightly by a couple people:
SVN r49961 by mpp@ addressing PR docs/13148 and docs/13144
Prior to-which the message said 3 years past (s/3/several/)
SVN r40275 by jkh@ (no PR mentioned)
Prior to-which the message said 2 years past (s/2/3/)
So, literally for the past 15+ years, the man-page has said
essentially the same thing prototype ... in need of death.
I raise the hypothesis that:
a. The prototype ... in need of death message in the man-page was
added by the original author, whom...
b. ...had self-esteem issues on that particular day (hence the
self-denigrating remark about one's code).
I further pontificate that once the original author relinquished
control of sysinstall(8) (whomever that may be -- since commit logs
don't go back that far) that one of the 2-dozen-plus committers should
have removed that message to quell evident propagation of FUD against
sysinstall(8)).
Afterall, who's to say that sysinstall(8) was still a prototype when
it was being used for several major releases in production and
enterprise environments.
But instead, this entry in the man-page was not removed,
year
RE: Backup strategy for zfs + jail
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of bsd Sent: Tuesday, January 17, 2012 1:04 PM To: Liste FreeBSD Subject: Backup strategy for zfs + jail Hi, I have a simple 1U server with two disks that I have configured as a jail server. I want to setup a simple yet very efficient backup policy for my jail environment. This server is running a ZFS filesystem. Ideally I would like to backup the main zfsroot/jail and all subdirectories on a backup FTP server. . What kind of tool would you suggest ? I need to focus on : -- Simplicity of setup -- Ease of recovery -- Efficiency -- Compatibility with ZFS If you're running 9, give HAST a shot. TCP/IP block-level mirroring provided by HAST should be able to mirror the ZFS container in near-RT and be tolerant of things like network issues. -- 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: buildworld -DWITHOUT_OPENSSL fails at (lib/libbsnmp/libbsnmp (all)) (was: lib/libarchive (depend))
On Jan 13, 2012, at 7:28 PM, Devin Teske wrote:
Trying to buildworld in RELENG_9 with -DWITHOUT_OPENSSL and getting failures.
First failure we encountered required the following patch to get past
lib/libarchive (depend)...
--- lib/libarchive/config_freebsd.h.orig 2012-01-05 03:44:55.0
-0800
+++ lib/libarchive/config_freebsd.h 2012-01-13 18:43:46.0 -0800
@@ -176,9 +176,4 @@
#define ARCHIVE_HASH_SHA256_OPENSSL 1
#define ARCHIVE_HASH_SHA384_OPENSSL 1
#define ARCHIVE_HASH_SHA512_OPENSSL 1
-#else
-#define ARCHIVE_HASH_MD5_LIBC 1
-#define ARCHIVE_HASH_SHA1_LIBC 1
-#define ARCHIVE_HASH_SHA256_LIBC 1
-#define ARCHIVE_HASH_SHA512_LIBC 1
#endif
The above patch allowed the mkdep to succeed and later-compilation in the
same directory succeeded (yay).
However, you don't get far before the next error.
Making all in lib/libbsnmp/libbsnmp with -DWITHOUT_OPENSSL...
cc -I/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib -DHAVE_ERR_H
-DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_STDINT_H -DHAVE_INTTYPES_H
-DQUADFMT='llu' -DQUADXFMT='llx' -std=gnu99 -fstack-protector
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign -c
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:371:
error: conflicting types for 'snmp_passwd_to_keys'
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273: error:
previous declaration of 'snmp_passwd_to_keys' was here
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:384:
error: conflicting types for 'snmp_get_local_keys'
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274: error:
previous declaration of 'snmp_get_local_keys' was here
The solution to this appears to be the following patch:
= BEGIN PATCH ==
--- contrib/bsnmp/lib/snmpcrypto.c.orig 2011-09-22 17:51:37.0 -0700
+++ contrib/bsnmp/lib/snmpcrypto.c 2012-01-15 09:49:27.0 -0800
@@ -366,7 +366,7 @@ snmp_pdu_decrypt(const struct snmp_pdu *
return (SNMP_CODE_OK);
}
-int
+enum snmp_code
snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused)
{
if (user-auth_proto == SNMP_AUTH_NOAUTH
@@ -378,7 +378,7 @@ snmp_passwd_to_keys(struct snmp_user *us
return (SNMP_CODE_FAILED);
}
-int
+enum snmp_code
snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused,
uint32_t elen __unused)
{
== END PATCH ==
I'll file a PR later (still trying to get a successful build first).
--
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-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: buildworld -DWITHOUT_OPENSSL fails at usr.sbin/wpa/hostapd (depend) (was: lib/libbsnmp/libbsnmp (all) (was: lib/libarchive (depend)))
On Jan 15, 2012, at 10:11 AM, Devin Teske wrote:
On Jan 13, 2012, at 7:28 PM, Devin Teske wrote:
Trying to buildworld in RELENG_9 with -DWITHOUT_OPENSSL and getting failures.
First failure we encountered required the following patch to get past
lib/libarchive (depend)...
--- lib/libarchive/config_freebsd.h.orig2012-01-05 03:44:55.0
-0800
+++ lib/libarchive/config_freebsd.h 2012-01-13 18:43:46.0 -0800
@@ -176,9 +176,4 @@
#define ARCHIVE_HASH_SHA256_OPENSSL 1
#define ARCHIVE_HASH_SHA384_OPENSSL 1
#define ARCHIVE_HASH_SHA512_OPENSSL 1
-#else
-#defineARCHIVE_HASH_MD5_LIBC 1
-#defineARCHIVE_HASH_SHA1_LIBC 1
-#defineARCHIVE_HASH_SHA256_LIBC 1
-#defineARCHIVE_HASH_SHA512_LIBC 1
#endif
The above patch allowed the mkdep to succeed and later-compilation in the
same directory succeeded (yay).
However, you don't get far before the next error.
Making all in lib/libbsnmp/libbsnmp with -DWITHOUT_OPENSSL...
cc -I/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib -DHAVE_ERR_H
-DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_STDINT_H -DHAVE_INTTYPES_H
-DQUADFMT='llu' -DQUADXFMT='llx' -std=gnu99 -fstack-protector
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign -c
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:371:
error: conflicting types for 'snmp_passwd_to_keys'
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273: error:
previous declaration of 'snmp_passwd_to_keys' was here
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:384:
error: conflicting types for 'snmp_get_local_keys'
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274: error:
previous declaration of 'snmp_get_local_keys' was here
The solution to this appears to be the following patch:
= BEGIN PATCH ==
--- contrib/bsnmp/lib/snmpcrypto.c.orig 2011-09-22 17:51:37.0
-0700
+++ contrib/bsnmp/lib/snmpcrypto.c2012-01-15 09:49:27.0 -0800
@@ -366,7 +366,7 @@ snmp_pdu_decrypt(const struct snmp_pdu *
return (SNMP_CODE_OK);
}
-int
+enum snmp_code
snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused)
{
if (user-auth_proto == SNMP_AUTH_NOAUTH
@@ -378,7 +378,7 @@ snmp_passwd_to_keys(struct snmp_user *us
return (SNMP_CODE_FAILED);
}
-int
+enum snmp_code
snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused,
uint32_t elen __unused)
{
== END PATCH ==
Then you churn along for some lengthy time (even making it all the way through
clang successfully), but then stop again at usr.sbin/wpa/hostapd (depend)
(output at end).
Probably going to be a patch similar to the libarchive one.
--
Devin
=== usr.sbin/wpa/hostapd (depend)
rm -f .depend
mkdep -f .depend -a-DDRUID -I/usr/src/usr.sbin/wpa/hostapd
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//hostapd
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/drivers
-DCONFIG_DRIVER_BSD -DHOSTAPD -DCONFIG_DRIVER_RADIUS_ACL -DCONFIG_IPV6
-DEAP_TLS_NONE -DINTERNAL_AES -DINTERNAL_SHA1 -DINTERNAL_MD5
-I/usr/src/usr.sbin/wpa/hostapd
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/accounting.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto/aes-wrap.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_config.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_drv_ops.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_mlme.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/authsrv.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/eap_common/chap.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils/common.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//hostapd/config_file.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa
Re: buildworld -DWITHOUT_OPENSSL fails at usr.sbin/wpa/wpa_supplicant (all) (was usr.sbin/wpa/hostapd (depend) (was: lib/libbsnmp/libbsnmp (all) (was: lib/libarchive (depend))))
On Jan 15, 2012, at 10:43 AM, Devin Teske wrote:
On Jan 15, 2012, at 10:11 AM, Devin Teske wrote:
On Jan 13, 2012, at 7:28 PM, Devin Teske wrote:
Trying to buildworld in RELENG_9 with -DWITHOUT_OPENSSL and getting
failures.
First failure we encountered required the following patch to get past
lib/libarchive (depend)...
--- lib/libarchive/config_freebsd.h.orig 2012-01-05 03:44:55.0
-0800
+++ lib/libarchive/config_freebsd.h2012-01-13 18:43:46.0
-0800
@@ -176,9 +176,4 @@
#defineARCHIVE_HASH_SHA256_OPENSSL 1
#defineARCHIVE_HASH_SHA384_OPENSSL 1
#defineARCHIVE_HASH_SHA512_OPENSSL 1
-#else
-#define ARCHIVE_HASH_MD5_LIBC 1
-#define ARCHIVE_HASH_SHA1_LIBC 1
-#define ARCHIVE_HASH_SHA256_LIBC 1
-#define ARCHIVE_HASH_SHA512_LIBC 1
#endif
The above patch allowed the mkdep to succeed and later-compilation in the
same directory succeeded (yay).
However, you don't get far before the next error.
Making all in lib/libbsnmp/libbsnmp with -DWITHOUT_OPENSSL...
cc -I/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib
-DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_STDINT_H
-DHAVE_INTTYPES_H -DQUADFMT='llu' -DQUADXFMT='llx' -std=gnu99
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
-Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
-Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:371:
error: conflicting types for 'snmp_passwd_to_keys'
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273:
error: previous declaration of 'snmp_passwd_to_keys' was here
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:384:
error: conflicting types for 'snmp_get_local_keys'
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274:
error: previous declaration of 'snmp_get_local_keys' was here
The solution to this appears to be the following patch:
= BEGIN PATCH ==
--- contrib/bsnmp/lib/snmpcrypto.c.orig 2011-09-22 17:51:37.0
-0700
+++ contrib/bsnmp/lib/snmpcrypto.c 2012-01-15 09:49:27.0 -0800
@@ -366,7 +366,7 @@ snmp_pdu_decrypt(const struct snmp_pdu *
return (SNMP_CODE_OK);
}
-int
+enum snmp_code
snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused)
{
if (user-auth_proto == SNMP_AUTH_NOAUTH
@@ -378,7 +378,7 @@ snmp_passwd_to_keys(struct snmp_user *us
return (SNMP_CODE_FAILED);
}
-int
+enum snmp_code
snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused,
uint32_t elen __unused)
{
== END PATCH ==
Then you churn along for some lengthy time (even making it all the way
through clang successfully), but then stop again at usr.sbin/wpa/hostapd
(depend) (output at end).
Probably going to be a patch similar to the libarchive one.
--
Devin
=== usr.sbin/wpa/hostapd (depend)
rm -f .depend
mkdep -f .depend -a-DDRUID -I/usr/src/usr.sbin/wpa/hostapd
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//hostapd
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/drivers
-DCONFIG_DRIVER_BSD -DHOSTAPD -DCONFIG_DRIVER_RADIUS_ACL -DCONFIG_IPV6
-DEAP_TLS_NONE -DINTERNAL_AES -DINTERNAL_SHA1 -DINTERNAL_MD5
-I/usr/src/usr.sbin/wpa/hostapd
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/accounting.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto/aes-wrap.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_config.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_drv_ops.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_mlme.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/authsrv.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/eap_common/chap.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils/common.c
/usr/src/usr.sbin/wpa/hostapd
Re: buildworld -DWITHOUT_OPENSSL fails at usr.sbin/wpa/wpa_supplicant (all) (was usr.sbin/wpa/hostapd (depend) (was: lib/libbsnmp/libbsnmp (all) (was: lib/libarchive (depend))))
On Jan 15, 2012, at 5:57 PM, Devin Teske wrote:
On Jan 15, 2012, at 10:43 AM, Devin Teske wrote:
On Jan 15, 2012, at 10:11 AM, Devin Teske wrote:
On Jan 13, 2012, at 7:28 PM, Devin Teske wrote:
Trying to buildworld in RELENG_9 with -DWITHOUT_OPENSSL and getting
failures.
First failure we encountered required the following patch to get past
lib/libarchive (depend)...
--- lib/libarchive/config_freebsd.h.orig 2012-01-05 03:44:55.0
-0800
+++ lib/libarchive/config_freebsd.h 2012-01-13 18:43:46.0
-0800
@@ -176,9 +176,4 @@
#define ARCHIVE_HASH_SHA256_OPENSSL 1
#define ARCHIVE_HASH_SHA384_OPENSSL 1
#define ARCHIVE_HASH_SHA512_OPENSSL 1
-#else
-#define ARCHIVE_HASH_MD5_LIBC 1
-#define ARCHIVE_HASH_SHA1_LIBC 1
-#define ARCHIVE_HASH_SHA256_LIBC 1
-#define ARCHIVE_HASH_SHA512_LIBC 1
#endif
The above patch allowed the mkdep to succeed and later-compilation in the
same directory succeeded (yay).
However, you don't get far before the next error.
Making all in lib/libbsnmp/libbsnmp with -DWITHOUT_OPENSSL...
cc -I/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib
-DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_STDINT_H
-DHAVE_INTTYPES_H -DQUADFMT='llu' -DQUADXFMT='llx' -std=gnu99
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
-Wnested-externs -Wredundant-decls -Wold-style-definition
-Wno-pointer-sign -c
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:371:
error: conflicting types for 'snmp_passwd_to_keys'
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273:
error: previous declaration of 'snmp_passwd_to_keys' was here
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:384:
error: conflicting types for 'snmp_get_local_keys'
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274:
error: previous declaration of 'snmp_get_local_keys' was here
The solution to this appears to be the following patch:
= BEGIN PATCH ==
--- contrib/bsnmp/lib/snmpcrypto.c.orig 2011-09-22 17:51:37.0
-0700
+++ contrib/bsnmp/lib/snmpcrypto.c 2012-01-15 09:49:27.0 -0800
@@ -366,7 +366,7 @@ snmp_pdu_decrypt(const struct snmp_pdu *
return (SNMP_CODE_OK);
}
-int
+enum snmp_code
snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused)
{
if (user-auth_proto == SNMP_AUTH_NOAUTH
@@ -378,7 +378,7 @@ snmp_passwd_to_keys(struct snmp_user *us
return (SNMP_CODE_FAILED);
}
-int
+enum snmp_code
snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused,
uint32_t elen __unused)
{
== END PATCH ==
Then you churn along for some lengthy time (even making it all the way
through clang successfully), but then stop again at usr.sbin/wpa/hostapd
(depend) (output at end).
Probably going to be a patch similar to the libarchive one.
--
Devin
=== usr.sbin/wpa/hostapd (depend)
rm -f .depend
mkdep -f .depend -a-DDRUID -I/usr/src/usr.sbin/wpa/hostapd
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//hostapd
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/drivers
-DCONFIG_DRIVER_BSD -DHOSTAPD -DCONFIG_DRIVER_RADIUS_ACL -DCONFIG_IPV6
-DEAP_TLS_NONE -DINTERNAL_AES -DINTERNAL_SHA1 -DINTERNAL_MD5
-I/usr/src/usr.sbin/wpa/hostapd
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/accounting.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto/aes-wrap.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_config.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_drv_ops.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_mlme.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/authsrv.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/eap_common/chap.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils/common.c
