Re: Defaults in 10.0 ZFS through bsdinstall

2013-11-15 Thread Kimmo Paasiala 
On Fri, Nov 15, 2013 at 5:36 PM, Mark Felder  wrote:
>
>
> On Fri, Nov 15, 2013, at 3:23, Stefan Esser wrote:
>> Am 14.11.2013 22:02, schrieb Teske, Devin:
>> > On Nov 14, 2013, at 12:49 PM, Mark Felder wrote:
>> >> We don't even do installs on UFS with atime disabled by default in fstab
>> >> so why should we so suddenly change course for ZFS?
>> >>
>> >
>> > You've made a good point.
>>
>> There is major difference between UFS and ZFS: UFS allows in-place
>> updates of i-node fields (like atime), while ZFS uses COW for all
>> data, file contents and meta-data like the i-nodes.
>>
>> With atime ON on UFS you'll see a small number of writes on
>> file-systems that are only read - we are used to accept that.
>>
>> On ZFS every update of atime causes a write of the meta-data to
>> a free location on disk, then updates of all data structures
>> that reference that meta-data up to the root of the tree (the
>> uberblock). An update of a few bytes turns out to write tens
>> of KB for each atime update (within the TXG sync interval, which
>> defaults to 5 seconds on FreeBSD). If you create snapshots, then
>> each snapshot will contain a copy of the metadata that was valid
>> at the time of the snapshot (well, that's not so different from
>> the situation with UFS snapshots, just that the data structures
>> are much more complex and larger in the ZFS case). Due to the
>> ease and speed of snapshot creation with ZFS there probably are
>> a magnitude or more snapshots on a typical ZFS system than on
>> one using UFS (I currently have a few hundred and have turned off
>> periodic snapshot generation on many unimportant file-systems,
>> already).
>>
>> I really hope that we get relatime (with minor variations that
>> were discussed a few months ago) and that we make it the default
>> in some future release ...
>>
>
> Thanks for this in-depth explanation. I wasn't aware that atime was
> quite so expensive on ZFS.


What I did on my system when I was still using ZFS was that I set
atime off by default but enabled it explicitly on /var/mail and /home
datasets. The thought was that it's needed for mailboxes in /var/mail
and if I then decide to move the inboxes to user's home directories I
won't get any surprises. Would that be a suitable compromise here?


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

Re: freebsd-version(1) enchancement

2013-11-12 Thread Kimmo Paasiala 
On Tue, Nov 12, 2013 at 11:56 AM, Dag-Erling Smørgrav  wrote:
> Kimmo Paasiala  writes:
>> Would it make sense to also include the svnversion(1) of the system
>> sources in the version output?
>
> No.  It is not available in the most important use case for
> freebsd-version(1), i.e. freebsd-update builds.
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no

I didn't express myself well enough I guess. What I'm after is
inclusion of the svnversion(1) information to a binary that gets
always built and installed as part of 'make buildworld/installworld'
regardless of src.conf(5) settings so that it would be possible to
identify the SVN version where the currently installed world comes
from. Now that I think loader(8) is not a good candidate for that
because of WITHOUT_BOOT. I was hoping that freebsd-version would be
such binary but since it's only a shell script that extracts the
information from various binaries it won't work unless those other
binaries have that information included in them.

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

Re: freebsd-version(1) enchancement

2013-11-12 Thread Kimmo Paasiala 
On Tue, Nov 12, 2013 at 11:16 AM, Kimmo Paasiala  wrote:
> I didn't even know this tool existed before tried to complete
> freebsd- today, very nice.
>
> Would it make sense to also include the svnversion(1) of the system
> sources in the version output? Maybe with a separate option (-u
> perhaps?) if it's not ok to change the meaning of -k and -u options
> anymore.
>
> -Kimmo

Woops... I just noticed freebsd-version is nothing but a shell script.
In that case could the svnversion(1) information be included in the
loader(8) binary? There's already a timestamp in it like this:

# strings /boot/loader | grep -A2 "bootstrap loader"

FreeBSD/x86 bootstrap loader
Sat Nov  9 15:29:40 EET 2013
t...@freebsd10.rdnzl.info

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

freebsd-version(1) enchancement

2013-11-12 Thread Kimmo Paasiala 
I didn't even know this tool existed before tried to complete
freebsd- today, very nice.

Would it make sense to also include the svnversion(1) of the system
sources in the version output? Maybe with a separate option (-u
perhaps?) if it's not ok to change the meaning of -k and -u options
anymore.

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

Re: cron(8) improvement

2013-11-07 Thread Kimmo Paasiala 
On Fri, Nov 8, 2013 at 5:42 AM, Lyndon Nerenberg  wrote:
>
> On Nov 7, 2013, at 19:41, Allan Jude  wrote:
>
>> it really depends on the port and what the cron
>> is doing.
>
> Why?  Can you give some specific examples?

I don't like the idea of having untracked files installed by the rc(8)
script. Why not install the cron.d snippet by default but leave
everything in it commented out with instructions at the beginning to
uncomment the contents to enable it?

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

Re: cron(8) improvement

2013-11-07 Thread Kimmo Paasiala 
On Thu, Nov 7, 2013 at 6:43 AM, Lyndon Nerenberg  wrote:
>
> On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala  wrote:
>
>> What's wrong with using the existing tools for achieving the same
>> effect? Periodic can be adapted to do exactly what you're describing
>> as noted above by adding an hourly (even minutely? :D ) periodic run.
>
> Periodic is geared towards periodic system maintenance tasks.  Once per day, 
> once per week, once per month.  It doesn't deal with tasks that need to be 
> fired off at arbitrary intervals.
>
> As you say, it could be adapted to run things with per-minute granularity, 
> but it wouldn't scale well.  For per-minute granularity you would have to 
> fire off a periodic run every minute.  That's five times the rate that 
> atrun(8) kicks off at.  That's a lot of overhead for small, embedded, or 
> power constrained systems.  And to get the time-granularity cron has, you 
> would have to re-implement cron(8)s dispatch control as a set of shell 
> functions.  That's just silly.
>
>
> --lyndon
>
>

Well ok, I get your point. I guess there's no other option than to add
support for a cron.d directory for crontab -snippets. I'd however like
to emphasize one thing that has been noted already:

- Snippets installed by ports should be disabled by default and
enabled only selectively by variables in rc.conf(5) or some other
configuration file to mirror what periodic(8) is doing now.  This is
an absolute must because having them enabled by default is a recipe
for disaster. Compare this to services installed by ports, none of
them are enabled by default.

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

Re: cron(8) improvement

2013-11-06 Thread Kimmo Paasiala 
On Thu, Nov 7, 2013 at 4:27 AM, Allan Jude  wrote:
> On 2013-11-06 20:49, Mark Felder wrote:
>>
>> On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote:
>>> On Nov 5, 2013, at 9:31 AM, Allan Jude  wrote:
>>>
 This came up in discussion on IRC and I thought I should throw it at the
 list so I don't forget.

 A user was asking how to do what linux cron does, where there is a
 directory /etc/cron.d/ that packages and add files to to create crontabs.

 Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and
 /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very
 useful feature, especially for pkg(8) as it makes it easy and safe to
 programatically add and remove crontabs as part of a package.
>>> This is a good idea.  We should do it.
>>>
>>> How and if this facility gets used is a separate question.
>>>
>>> "Tools, not policy."
>>>
>>> Support for a cron.d directory is a tool that can be
>>> used in many ways.  The policy of how it should be
>>> used is a separate discussion.  (For example, whether
>>> or not ports or packages should install crontab files into
>>> /usr/local/etc/cron.d/ can be richly debated after that
>>> directory exists.)
>>>
>> Ok, so we create that directory. Now nobody can use it in a port until
>> FreeBSD 8.4 is EoL -- approximately June 30, 2015.
>>
>> We should be using the existing cron tabs directory *now*. We can't
>> easily force older versions of FreeBSD to update their cron software or
>> configuration to support that new directory.
>>
>> I'm not saying we shouldn't create it, just that we can't effectively
>> use it for 2 years.
>> ___
>> freebsd-current@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> My use case is less about packages, and more about puppet, ansible etc.
> Puppet relies on these hideously large markers in the crontab files to
> programmatically add/remove crons, whereas a cron.d directory could be
> done nice and clean
>
> And in that case, the fact that it is not supported on 8.x does not
> bother me.
>
> --
> Allan Jude
>
>

What's wrong with using the existing tools for achieving the same
effect? Periodic can be adapted to do exactly what you're describing
as noted above by adding an hourly (even minutely? :D ) periodic run.
Also periodic already has support for ports installing their own jobs
under /usr/local/etc/periodic.d that can be enabled/disabled in
periodic.conf.

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

Re: [PATCH] contrib/groff Queisce -Wdangling else

2013-10-26 Thread Kimmo Paasiala 
On Sun, Oct 27, 2013 at 12:04 AM,   wrote:
> Sean Bruno wrote, On 10/26/2013 17:04:
>

>
> RED ALERT ! SEAN BRUNO IS A GOVERNMENT SPY 1
>

If this is an attempt at humor it's pretty lame one.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 10.0-BETA1 ZFS install -- /var/empty read-only

2013-10-23 Thread Kimmo Paasiala 
On Wed, Oct 23, 2013 at 4:29 PM, Kimmo Paasiala  wrote:
> On Wed, Oct 23, 2013 at 4:25 PM, Eric van Gyzen  wrote:
>> I just installed 10.0-BETA1 using the [very cool] new automatic ZFS
>> option.  I noticed that /var/empty is not mounted read-only.  I suspect
>> it could be.  I made it so, and sshd still seemed to work.
>>
>> Eric
>
> I don't think there's a standard for how to break down the ZFS pool to
> individual datasets. If the install made only a single dataset for
> /var you would then effectively get a read-write /var/empty. The

*The same applies*

> applies if you install on UFS and don't assign a separate filesystem
> for /var/empty like the default install does in fact.
>
> -Kimmo
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 10.0-BETA1 ZFS install -- /var/empty read-only

2013-10-23 Thread Kimmo Paasiala 
On Wed, Oct 23, 2013 at 4:25 PM, Eric van Gyzen  wrote:
> I just installed 10.0-BETA1 using the [very cool] new automatic ZFS
> option.  I noticed that /var/empty is not mounted read-only.  I suspect
> it could be.  I made it so, and sshd still seemed to work.
>
> Eric

I don't think there's a standard for how to break down the ZFS pool to
individual datasets. If the install made only a single dataset for
/var you would then effectively get a read-write /var/empty. The
applies if you install on UFS and don't assign a separate filesystem
for /var/empty like the default install does in fact.

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

Re: panic: softdep_deallocate_dependencies: unrecovered I/O error

2013-10-23 Thread Kimmo Paasiala 
On Wed, Oct 23, 2013 at 2:49 PM,   wrote:
> Alexey Dokuchaev wrote, On 10/23/2013 06:26:
>
>> panic: softdep_deallocate_dependencies: unrecovered I/O error
>
>
> I've seen similar panics relatively often in the last few months, but I
> deemed them to be the cause of worn IDE cables and old (>10 year old) hard
> drives.
>
> In fact, I have a core dump (which I apparently forgot to remove -- it's
> probably useless anyway) with the following panic string:
>
>   softdep_deallocate_dependencies: dangling deps
>

I had similar problems on a stable/10 10.0-BETA1 system that was
running as a guest on VirtualBox. I switched the system to real
hardware and the problems went away immediately. Now I have two
different i386 stable/10 systems running on real hardware, neither has
had any crashing problems so far.

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

Re: rcs

2013-10-09 Thread Kimmo Paasiala 
On Wed, Oct 9, 2013 at 2:03 PM, George Mitchell  wrote:
> On 10/09/13 03:20, Hans Ottevanger wrote:
>>
>> On 10/08/13 04:31, Lyndon Nerenberg wrote:
>>>
>>> Okay folks, can we make a call about keeping the RCS tools in the base?
>>>
>>> The proponents wanting to remove RCS need to speak up and make their
>>> technical case.
>>>
>>
>> Technically it is quite simple: I need RCS to start versioning config
>> files, even before starting any customization. I know about several
>> others who do the same (and have not yet defected to Linux).
>>
>> I would like to see RCS to be put back into the tree for 10.0. If it
>> really -has- to be victimized by the current anti-GPL crusade, it could
>> be replaced by OpenRCS in 11.
>>
>> And as a long time hard-core user I would appreciate if this kind of
>> changes were  performed only after at least -some- public discussion.
>> The way this change was sneaked in (though apparently with approval of
>> core@),  reminds me more of a Secret Society than of an Open Source
>> project.
>>
>> Regards,
>>
>> Hans
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>
>
> +1, enthusiastically. -- George
>

+1 also to OpenRCS allthough I hate anything related to RCS/CVS with a
passion. I do however recognize the need for a simple revision control
system in the base, svnlite would fill the need maybe but it's good to
have other options too.

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

Re: bug with special bracket expressions in regular expressions

2013-09-02 Thread Kimmo Paasiala 
On Mon, Sep 2, 2013 at 7:45 PM, Andriy Gapon  wrote:
> on 02/09/2013 17:54 Andriy Gapon said the following:
>>
>> re_format(7) says:
>>  There are two special cases‡ of bracket expressions: the bracket expres‐
>>  sions ‘[[:<:]]’ and ‘[[:>:]]’ match the null string at the beginning and
>>  end of a word respectively.  A word is defined as a sequence of word
>>  characters which is neither preceded nor followed by word characters.  A
>>  word character is an alnum character (as defined by ctype(3)) or an
>>  underscore.  This is an extension, compatible with but not specified by
>>  IEEE Std 1003.2 (“POSIX.2”), and should be used with caution in software
>>  intended to be portable to other systems.
>>
>> However I observe the following:
>> $ echo "cd0 cd1 xx" | sed 's/cd[0-9][^ ]* *//g'
>> xx
>> $ echo "cd0 cd1 xx" | sed 's/[[:<:]]cd[0-9][^ ]* *//g'
>> cd1 xx
>>
>> In my opinion '[[:<:]]' should not affect how the pattern is matched in this 
>> case.
>
> It seems that the code works like this:
> - first it matches "cd0 " and "removes" it
> - then it passes "cd1 xx" for matching with a flag that tells that this is not
>   a real start of the string
> - thus the matching code
>  o knows that this is not a real line start, so it can't match [[:<:]]
>just for that reason
>  o it does _not_ know what was the character before the start of the given
>substring, so it can not know if it could match [[:<:]]
>
> So matching fails.
> Not sure if this is an internal problem of regex(3) or a problem of how sed(1)
> uses regex(3).
>
> --
> Andriy Gapon

In my opinion this is a bug. The [[:<:]] operator is said to match the
empty string at the beginning of a word with no mention that the word
has to be at the beginning of the whole string that is matched. OS X
version of sed(1) works differently:

$ echo "cd0 cd1 xx" | sed 's/cd[0-9][^ ]* *//g'
xx
$ echo "cd0 cd1 xx" | sed 's/[[:<:]]cd[0-9][^ ]* *//g'
xx

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

Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC?

2013-08-29 Thread Kimmo Paasiala 
In reference to this FreeBSD forums post:

http://forums.freebsd.org/showpost.php?p=231135&postcount=4

Would it be a good time to remove those from GENERIC since the
hardware they are for is becoming so seriously outdated?

There's always an option to load those drivers as modules if needed.

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

Re: route get fails

2013-08-24 Thread Kimmo Paasiala 
On Sat, Aug 24, 2013 at 2:42 PM, Pawel Pekala  wrote:
> Hi,
>
> For some time now I get this:
>
> [corn:~]> route get
> route: writing to routing socket: Invalid argument
>
> Is this just my build or anyone can confirm this?
>
> --
> pozdrawiam / with regards
> Paweł Pękala

Nothing wrong there, you're not providing a required argument that is
the destination IP address. In my opinion route(8) should return a
proper error message in this case. OS X route(8) behaves exactly the
same BTW.

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

Re: ipv6_activate_all_interfaces doesn't work on wireless interface.

2013-08-16 Thread Kimmo Paasiala 
On Fri, Aug 16, 2013 at 8:47 AM, Eric L Camachat
 wrote:
> Here is my /etc/rc.conf
> ipv6_enable="YES"
> #ip6addrctl_enable="YES"
> #ip6addrctl_policy="ipv6_prefer"
> #ipv6_activate_all_interfaces="YES"
> wlans_iwn0="wlan0"
> ifconfig_wlan0="WPA DHCP"
>
> rc.d system said ipv6_enable is obsoleted by
> ipv6_activate_all_interfaces.
> So, I tried to replaced ipv6_enable with ipv6_activate_all_interfaces
> and ip6addrctl_*, interface wlan0 will not get ipv6 address from router.
>
> After investigated, that's because of wlan0 didn't add 'accept_rtadv'
> ipv6 option.
>
> --
> Eric
>

As far as I know, not enabling accept_rtadv is a reasonable default
and it has been like that always. Just like DHCP is not a default
configuration method for IPv4 addresses.

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

Re: svn error during 'make buildkernel'?

2013-08-05 Thread Kimmo Paasiala 
On Mon, Aug 5, 2013 at 12:08 PM, Sergey V. Dyatko
 wrote:
> On Sun, 4 Aug 2013 20:57:04 -0400
> Glen Barber  wrote:
>
>> On Sun, Aug 04, 2013 at 05:50:28PM -0700, Steve Kargl wrote:
>> > If you are disinclined to fix your commit, then consider this
>> > an official request to back out revision 252505.
>> >
>>
>> You are the first and only one to complain after this change was in
>> effect for 2 months.
>>
>
> that is not true. _same_ ML:
> Jul,14
>  'lost my r2x subversion id in uname &
> kern.version'
>
>

Your problem is that don't really the UPDATING instructions. There are
clear instructions on how you can stay with the 1.7 version of
subversion. Nothing forces you to update to 1.8., that has been
already established in this discussion.

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

Re: [HEADSUP] No more pkg_install on HEAD by default

2013-07-13 Thread Kimmo Paasiala 
On Sat, Jul 13, 2013 at 7:46 PM, Teske, Devin  wrote:
>
> On Jul 13, 2013, at 8:17 AM, Teske, Devin wrote:
>
>
> On Jul 13, 2013, at 1:07 AM, Baptiste Daroussin wrote:
>
> On Fri, Jul 12, 2013 at 11:52:19PM +, Teske, Devin wrote:
> On Jul 12, 2013, at 4:16 PM, Baptiste Daroussin wrote:
>
> Hi,
>
> I have just committed (r253305) a change the make pkg_install not being built
> and installed by default on HEAD.
>
> If you are still relying on it, be careful and add WITH_PKGTOOLS=yes in your
> src.conf(5)
>
> [snip]
>
> I for one am effected and will have to change things.
>
> If you are referring to bsdconfig's package management,
>
> [snip] Yes. that's what I'm talking about. [snip]
>
>
> it is not working anyway
> HEAD as we do not and will not provides any pkg_install for HEAD via any of 
> the
> usual distribution process: http, ftp, CD.
>
>
>
> The FTP mirror of packages is going away? (if you said yes and pointed at a 
> prior conversation about leading up to this, I would not be surprised -- I'm 
> just questioning it because I don't see the value in pairing-down methods of 
> acquisition)
>
> If this is the case, what's the surviving acquisition method? A custom TCP 
> protocol perhaps?
>
> There may be those that wish to use pkg in the pkg_add manner and download 
> things and then inspect them manually before adding them. For example, I 
> often go the freshports.org to find a package that 
> fills a need... download it from the official FTP server(s), inspect all of 
> them, and choose the one that best fits me need (and only then installing 
> from the local file; tossing the rest). If I go through the "pkg" tool, I 
> have to inspect things *after* they've been installed which is not to my 
> satisfaction.
>
>
> [snip
> bsdconfig is not installed by
> default,
>
> Wrong, please see...
> http://svnweb.freebsd.org/base?view=revision&revision=252862
> [snip]
>
> The first thing that comes to mind in reprogramming bsdconfig's package 
> management for pkgng...
>
> We have a *very* large list of FTP mirrors. This will presumably be replaced 
> with a list of "pkg" mirrors.
>
> Do we have such a list that we want to program into the base configuration of 
> bsdconfig?
> --
> Devin
>

Come on, this only concerns 10-CURRENT. Where is it stated that the
FTP mirrors for FreeBSD 8/9 packages are going away?

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

config(8) -x headscratcher

2013-04-27 Thread Kimmo Paasiala 
I'm getting a core dump on 'config -x /boot/kernel/kernel' on 9.1-RELEASE i386.

Assertion failed: (r != '\0' && ("Char present in the configuration "
"string mustn't be equal to 0")), function kernconfdump, file
/usr/src/usr.sbin/config/main.c, line 710.

I have double checked that my config file is sane and does not have
any funny characters anywhere.

The system is i386 9.1-RELEASE r249856. The world and kernel are built
with clang and I'm suspecting that the use of clang has something to
do with this segfault.

Looking at the kernel files I can see one very obvious difference.
This is the 'elfdump -c kernel | grep -A 8 kern_conf' output (what
config -x seems to use for finding out the config file from the kernel
image) for the GENERIC kernel from the stock installation:

sh_name: kern_conf
sh_type: SHT_PROGBITS
sh_flags: SHF_ALLOC
sh_addr: 0xc1039f80
sh_offset: 12820352
sh_size: 3771
sh_link: 0
sh_info: 0
sh_addralign: 32

And this is from the kernel I have built myself using clang and a
custom config file:

sh_name: kern_conf
sh_type: SHT_PROGBITS
sh_flags: SHF_ALLOC
sh_addr: 0xc09aee9c
sh_offset: 5959324
sh_size: 1994
sh_link: 0
sh_info: 0
sh_addralign: 1

The align field looks suspicious, config -x seems to use it to check
for padding but to me it looks like the logic may not work if the
alignment is 1.

This the relevant bit from main.c of config(8)

if (r == '\0' && (size - i) < align)
break;
assert(r != '\0' && ("Char present in the configuration "
"string mustn't be equal to 0"));
fputc(r, stdout);


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

Re: WORLDTMP on a ram disk

2013-04-20 Thread Kimmo Paasiala 
On Sat, Apr 20, 2013 at 3:16 PM, Dimitry Andric  wrote:
> On Apr 20, 2013, at 11:55, Kimmo Paasiala  wrote:
>> Poking around the /usr/src/Makefile.inc1 I see that there's a variable
>> called "WORLDTMP" that seems to set the location for temporary files
>> during the world build. My question is now:
>>
>> Is it safe to put WORLDTMP on a ram disk, for example tmpfs(5)?
>>
>> Looking at the build process it seems to me that the temporary files
>> are no longer needed after make buildworld has finished?
>
>
> The problem is that you need those temporary files for installworld, and
> you must reboot with your new kernel before running that...
>

Well that was what I was after, I was somehow under the impression
that the files in WORLDTMP would be moved to more permanent location
under /usr/obj for installworld to find them.

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

WORLDTMP on a ram disk

2013-04-20 Thread Kimmo Paasiala 
Poking around the /usr/src/Makefile.inc1 I see that there's a variable
called "WORLDTMP" that seems to set the location for temporary files
during the world build. My question is now:

Is it safe to put WORLDTMP on a ram disk, for example tmpfs(5)?

Looking at the build process it seems to me that the temporary files
are no longer needed after make buildworld has finished?

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

Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD)

2013-04-15 Thread Kimmo Paasiala 
On Tue, Apr 16, 2013 at 1:44 AM, George Mitchell  wrote:
> On 04/15/13 18:09, Sean Bruno wrote:
>>
>> On Mon, 2013-04-15 at 15:58 -0400, George Mitchell wrote:
>>>
>>> that does not respond to key presses on the keyboard.  It times out
>>> and
>>> continues loading anyway.  At this stage, I am always presented with a
>>> manual mountroot: prompt, and I have to type "ufs:/dev/ada0s1a" to get
>>> any further.
>>>
>>>
>>
>> Hrm ... is /dev/ada0s1a the default root disk in your /etc/fstab ?
>>
>> Sean
>>
> Yes:
>
> # DeviceMountpoint  FStype  Options Dump Pass#
> /dev/ada0s1bnoneswapsw  0   0
> /dev/ada0s1a/   ufs rw  1   1
> [...]
>
>
>
Change the order so that the root device is the first in /etc/fstab.

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

Re: ipfilter(4) needs maintainer

2013-04-15 Thread Kimmo Paasiala 
On Mon, Apr 15, 2013 at 1:54 PM, Kimmo Paasiala  wrote:
> On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov  wrote:
>> Hello, Kimmo.
>> You wrote 15 апреля 2013 г., 14:47:24:
>>
>> KP> I'm however talking about an ftp client behind a very restrictive
>> KP> firewall making an IPv6 connection an ftp server that uses passive
>> KP> mode data ports that can't be known in advance.
>>   Same solution -- inspection of connections to 21 port, without any
>>  address translation. And if FTP server uses non-standard control
>>  port, yes, here is a problem, but it cannot be solved with NAT too
>>  (or your NAT/firewall should expect each and every connection for FTP
>>  commands, which is heavy and error-prone task).
>>
>
> Mmm, are you thinking of the way Linux iptables handles this scenario
> with a kernel mode helper? I don't think any of the three packet
> filters in FreeBSD has a functionality like that yet.
>
> -Kimmo

To elaborate on this, Linux iptables has a "related" qualifier for
rules and the "related" traffic is identified by kernel mode helpers,
ftp is one example for their use.

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

Re: ipfilter(4) needs maintainer

2013-04-15 Thread Kimmo Paasiala 
On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov  wrote:
> Hello, Kimmo.
> You wrote 15 апреля 2013 г., 14:47:24:
>
> KP> I'm however talking about an ftp client behind a very restrictive
> KP> firewall making an IPv6 connection an ftp server that uses passive
> KP> mode data ports that can't be known in advance.
>   Same solution -- inspection of connections to 21 port, without any
>  address translation. And if FTP server uses non-standard control
>  port, yes, here is a problem, but it cannot be solved with NAT too
>  (or your NAT/firewall should expect each and every connection for FTP
>  commands, which is heavy and error-prone task).
>

Mmm, are you thinking of the way Linux iptables handles this scenario
with a kernel mode helper? I don't think any of the three packet
filters in FreeBSD has a functionality like that yet.

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

Re: ipfilter(4) needs maintainer

2013-04-15 Thread Kimmo Paasiala 
On Mon, Apr 15, 2013 at 1:44 PM, Lev Serebryakov  wrote:
> Hello, Kimmo.
> You wrote 15 апреля 2013 г., 14:36:27:
>
>>>  And, yes, NAT64 will be useful for sure, but it is another story,
>>> not IPv6<->IPv6 translation.
> KP> You're forgetting set ups where outgoing traffic is controlled by
> KP> filter rules, outgoing passive mode ftp needs help from the proxy to
> KP> open holes for arbitrary ports. This is not limited to IPv4 and NAT.
>It could  be  done without IPv6 prefix mapping. Yes, firewall should
>  have  ability  to expect some connections fro FTP commands (some flag
>  on rule, for sure), but it is not prefix rewriting (there are some
>  other protocols, which need similar treatment, like SIP)! I was
>  shocked by idea of true NAT from IPv6 to IPv6. IPv6 has its own
>  problems and complications, but one REALLY GOOD side of it, that we
>  don't need NAT for it anymore! Some special tricks in firewall -- yes,
>  maybe, for bad-designed, but widely-deployed application level
>  protocols, but not address translations!
>
>   I, personally, don't see any problems to enable all outbound
>  connections for dedicated FTP server, though.
>

Server side is the easy part, no need for proxy because you know the
passive mode data ports and you can open holes in your firewall using
the known port numbers.

I'm however talking about an ftp client behind a very restrictive
firewall making an IPv6 connection an ftp server that uses passive
mode data ports that can't be known in advance.

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

Re: ipfilter(4) needs maintainer

2013-04-15 Thread Kimmo Paasiala 
On Mon, Apr 15, 2013 at 1:38 PM, Slawa Olhovchenkov  wrote:
> On Mon, Apr 15, 2013 at 02:15:36PM +0400, Lev Serebryakov wrote:
>
>> >> Yes! This is the most clever thought in this thread. Why we need 3
>> >> firewalls? Two packet filters it's excess too. We have two packet filters:
>> >> one with excellent syntax and functionality but with outdated bandwidth
>> >> control mechanism (aka ALTQ); another - with nice traffic
>> >> shaper/prioritization (dummynet)/classification (diffused) but with
>> >> complicated implementation  in not trivial tasks. May be the next step
>> >> will be discussion about one packet filter in the system?..
>>
>> MM> ... and as far as I can tell none of them is currently usable
>> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
>> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
>>  IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will
>> render all that NAT nightmare to void. I hope, IPv6 prefix translation
>> will not be possible never ever!
>
> You disallow anonymization? NAT do anonymisation also.
> ___

Please stop it already, NAT has never done any real anonymisation.
it's just one of the myths that just refuse to die. Use a real
anonymiser like Tor if you want to keep your identity hidden.

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

Re: ipfilter(4) needs maintainer

2013-04-15 Thread Kimmo Paasiala 
On Mon, Apr 15, 2013 at 1:32 PM, Lev Serebryakov  wrote:
> Hello, Kimmo.
> You wrote 15 апреля 2013 г., 14:26:40:
>
>>> MM> ... and as far as I can tell none of them is currently usable
>>> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
>>> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
>>>  IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will
>>> render all that NAT nightmare to void. I hope, IPv6 prefix translation
>>> will not be possible never ever!
>
> KP> Things like ftp-proxy(8) will need address translation even with IPv6.
>   ftp-proxy is solution to help IPv4 NAT. Why do we need it when every
> device could have routable IPv6? Of course, _every_ device should be
> protected by border firewall (stateful and IPv6-enabled), but FTP
> server should have special rules for it to allow traffic pass, not
> some "proxy".
>
>  And, yes, NAT64 will be useful for sure, but it is another story,
> not IPv6<->IPv6 translation.
>

You're forgetting set ups where outgoing traffic is controlled by
filter rules, outgoing passive mode ftp needs help from the proxy to
open holes for arbitrary ports. This is not limited to IPv4 and NAT.

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

Re: ipfilter(4) needs maintainer

2013-04-15 Thread Kimmo Paasiala 
On Mon, Apr 15, 2013 at 1:15 PM, Lev Serebryakov  wrote:
> Hello, Mark.
> You wrote 15 апреля 2013 г., 2:25:07:
>
>>> Yes! This is the most clever thought in this thread. Why we need 3
>>> firewalls? Two packet filters it's excess too. We have two packet filters:
>>> one with excellent syntax and functionality but with outdated bandwidth
>>> control mechanism (aka ALTQ); another - with nice traffic
>>> shaper/prioritization (dummynet)/classification (diffused) but with
>>> complicated implementation  in not trivial tasks. May be the next step
>>> will be discussion about one packet filter in the system?..
>
> MM> ... and as far as I can tell none of them is currently usable
> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
>  IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will
> render all that NAT nightmare to void. I hope, IPv6 prefix translation
> will not be possible never ever!
>
> --
> // Black Lion AKA Lev Serebryakov 
>

Things like ftp-proxy(8) will need address translation even with IPv6.
Also certain scrub options require a NAT like functionalities.

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

2013-04-13 Thread Kimmo Paasiala 
On Thu, Jan 17, 2013 at 7:24 AM, Kimmo Paasiala  wrote:
> On Thu, Dec 27, 2012 at 11:42 PM, Phil Kulin  wrote:
>> 2012/12/26 Kimmo Paasiala :
>>
>>> I've revised the patch again and updated it at gihub,
>>> https://gist.github.com/4362018.  It can now be applied at top level
>>> of sources (/usr/src typically). It now does the deconfiguration in
>>> reverse order of the configuration, meaning the aliases configured
>>> with ipv6_addrs_IF are removed before the ones configured with
>>> ifconfig_IF_aliasN="inet6 ...".
>>
>> Adapted for FreeBSD 8.2, works fine:
>>
>> --- network.subr.orig   2011-02-17 05:19:39.0 +0300
>> +++ network.subr2012-12-28 00:46:38.0 +0400
>> @@ -312,6 +312,12 @@ afexists()
>>  #  1 otherwise.
>>  ipv6if()
>>  {
>> +   # Test for $ipv6_addrs_IF. If it exists then the
>> +   # interface should be configured for IPv6
>> +   _tmpargs=$(get_if_var $_if ipv6_addrs_IF)
>> +   if [ -n "${_tmpargs}" ]; then
>> +   return 0
>> +   fi
>> if ! checkyesno ipv6_enable; then
>> return 1
>> fi
>> @@ -948,7 +954,12 @@ network6_interface_setup()
>> rtsol_interface=no
>> ifconfig $i inet6 ${ipv6_ifconfig} alias
>> fi
>> -
>> +   ipv6_addrs=`get_if_var $i ipv6_addrs_IF`
>> +   if [ -n "${ipv6_addrs}" ]; then
>> +   rtsol_available=no
>> +   rtsol_interface=no
>> +   ipv6_addrs_common ${i} alias
>> +   fi
>> # Wireless NIC cards are virtualized through the wlan 
>> interface
>> if ! is_wired_interface ${i}; then
>> case "${i}" in
>> @@ -1178,3 +1189,39 @@ network6_getladdr()
>> esac
>> done
>>  }
>> +
>> +ipv6_addrs_common()
>> +{
>> +   local _ret _if _action _ip6prefix _ip6prefixes
>> +   local _ip6addr _prefixlen
>> +   local _range _ip6net _ip6low _ip6high
>> +   _ret=1
>> +   _if=$1
>> +   _action=$2
>> +   # get the prefixes from ipv6_addrs_IF variable
>> +   _ip6prefixes=`get_if_var $_if ipv6_addrs_IF`
>> +   for _ip6prefix in ${_ip6prefixes}; do
>> +   _ip6addr=${_ip6prefix%%/*}
>> +   _prefixlen=${_ip6prefix##*/}
>> +   _range=${_ip6addr##*:}
>> +   _ip6net=${_ip6addr%:*}
>> +   _ip6low=${_range%-*}
>> +   _ip6high=${_range#*-}
>> +   # If deleting an alias, set _prefixlen to null string.
>> +   if [ "${_action}" = "-alias" ]; then
>> +   _prefixlen=""
>> +   else
>> +   _prefixlen="prefixlen $_prefixlen"
>> +   fi
>> +   _ip6high=$(("0x${_ip6high}"))
>> +   _ip6count=$(("0x${_ip6low}"))
>> +   while [ "${_ip6count}" -le "${_ip6high}" ]; do
>> +   # Re-uses the _ip6addr variable from above
>> +   _ip6addr=$(printf "%x" "${_ip6count}")
>> +   eval "ifconfig ${_if} inet6
>> ${_ip6net}:${_ip6addr} ${_prefixlen} ${_action}"
>> +   _ip6count=$((${_ip6count}+1))
>> +   _ret=0
>> +   done
>> +   done
>> +   return $_ret
>> +}
>>
>>
>> --
>> Non nobis Domine non nobis sed Nomini Tuo da gloriam
>> Phil Kulin
>
> I don't have an 8.X system to test but I guess it's fine.
>
> Any more interest in this? I'd love to see this added, not because I
> wrote it but because I want to contribute in any way I can.
>
> -Kimmo

Sorry to resurrect this thread but since nothing has happened in about
three months I have to ask: What can I do to have this commited to
HEAD? I'd be even willing to become a src committer if that's what is
required. I feel that I'm compentent enough. Who can I contact?

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

Re: ipfilter(4) needs maintainer

2013-04-13 Thread Kimmo Paasiala 
On Sat, Apr 13, 2013 at 3:03 PM, Scott Long  wrote:
>
> On Apr 13, 2013, at 12:33 AM, Rui Paulo  wrote:
>
>> On 2013/04/12, at 22:31, Scott Long  wrote:
>>
>>> On Apr 12, 2013, at 7:43 PM, Rui Paulo  wrote:
>>>
 On 2013/04/11, at 13:18, Gleb Smirnoff  wrote:

> Lack of maintainer in a near future would lead to bitrot due to changes
> in other areas of network stack, kernel APIs, etc. This already happens,
> many changes during 10.0-CURRENT cycle were only compile tested wrt
> ipfilter. If we fail to find maintainer, then a correct decision would be
> to remove ipfilter(4) from the base system before 10.0-RELEASE.

 This has been discussed in the past. Every time someone came up and said 
 "I'm still using ipfilter!" and the idea to remove it dies with it.
 I've been saying we should remove it for 4 years now. Not only it's 
 outdated but it also doesn't not fit well in the FreeBSD roadmap. Then 
 there's the question of maintainability. We gave the author a commit bit 
 so that he could maintain it. That doesn't happen anymore and it sounds 
 like he has since moved away from FreeBSD. I cannot find any reason to 
 burden another FreeBSD developer with maintaining ipfilter.

>>>
>>> One thing that FreeBSD is bad about (and this really applies to many open 
>>> source projects) when deprecating something is that the developer and 
>>> release engineering groups rarely provide adequate, if any, tools to help 
>>> users transition and cope with the deprecation.  The fear of deprecation 
>>> can be largely overcome by giving these users a clear and comprehensive 
>>> path forward.  Just announcing "ipfilter is going away.  EOM" is inadequate 
>>> and leads to completely justified complaints from users.
>>
>> I agree with the deprecation path, but given the amount of changes that 
>> happened in the last 6 months, I'm not even sure ipfilter is working fine in 
>> FreeBSD CURRENT, but I haven't tested it.
>>
>
> You target audience for this isn't people who track CURRENT, it's people who 
> are on 7, 8, or 9 and looking to update to 10.x sometime in the future.
>
>>> So with that said, would it be possible to write some tutorials on how to 
>>> migrate an ipfilter installation to pf?  Maybe some mechanical syntax docs 
>>> accompanied by a few case studies?  Is it possible for a script to automate 
>>> some of the common mechanical changes?  Also essential is a clear document 
>>> on what goes away with ipfilter and what is gained with pf.  Once those 
>>> tools are written, I suggest announcing that ipfilter is available but 
>>> deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11.  
>>> Certain people will still pitch a fit about it departing, but if the tools 
>>> are there to help the common users, you'll be successful in winning 
>>> mindshare and general support.
>>
>>
>> It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but 
>> I'm not sure automated tools exist. I'm also not convinced we need to write 
>> them and I think the issue can be deal with by writing a bunch of examples 
>> on how to do it manually. Then we can give people 1y to switch.
>>
>
> Please believe me that no matter how trivial you think the switch is, a 
> migration guide still needs to be written.
>
> Scott
> \

The migration guide is best written by the current users of ipfilter,
not those who have no interest in doing so because their interests are
completely elsewhere.

Please don't try to defer to an authority that does not exist here.

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

Re: updating ports to HEAD

2013-04-01 Thread Kimmo Paasiala 
On Tue, Apr 2, 2013 at 8:03 AM, Matthias Apitz  wrote:
> El día Monday, April 01, 2013 a las 08:54:59PM -0700, Kevin Oberman escribió:
>
>> > Is there something in the base system of r235646 which would not allow
>> > to do so, i.e. which is to old for HEAD of ports?
>> >
>>
>> I'm not quite sure what you mean by  "update /usr/ports with SVN to HEAD",
>> since ports does not branch, so any time you "svn up /usr/potrts", it is
>> updated to head.
>
> I used the term 'HEAD' because the SVN command I have used was:
>
> # svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports
>
>> Any version of FreeBSD 8 or newer should work fine with
>> ports/head.  Note that some ports will need to be compiled with gcc as not
>> all will work with clang.
>
> thanks;
>
>>
>> Are you having a problem updating (or checking out) head or with some of
>> the ports after the update?
>
> the system in question hast around 1200 ports compiled based on the CVS
> checkout of ports on May 19 last year; I want to check if I could
> compile Ekiga out of its GIT, wich needs gtk+3.4.x and other recent
> stuff; I will just for a test rename /usr/local and /var/db/pkg, update
> the ports to 'HEAD' and compile them again to see if this would solve
> the problem and make Ekiga happy.
>

I hope for your sake that this machine is not open to the net with
many services, using year old ports/packages is a death wish in such
systems. In any case it's a good idea to update everything at least
every two months about.

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

Re: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good

2013-03-25 Thread Kimmo Paasiala 
On Mon, Mar 25, 2013 at 10:44 PM, Andriy Gapon  wrote:
>
> Would like to ask for opinions on this topic...
> Please read this PR for context:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838
> Especially Jaakko's insightful description of the problem.
>
>
>  Original Message 
> Message-ID: <5150b598.7050...@freebsd.org>
> Date: Mon, 25 Mar 2013 22:37:44 +0200
> From: Andriy Gapon 
> Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like
> zvol/pool/vms) good
>
>
> Can't believe that we are still where we were more than two years ago...
>
> I think that we have to make this change even if it _might_ break some 
> existing
> rulesets.
>
> Rationale:
> - current behavior is contrary to any documentation
> - current behavior is contrary to common sense
> - current behavior is very hard to describe and account for
> - I presume that very few people actually fully understand the current 
> behavior
> - I presume that even fewer people made a conscious choice to depend or make 
> use
> of its non-trivial features of the current behavior
>
> So, we should make the behavior of devfs pattern consistent with the
> documentation and the common sense.
>
> In addition to Jaakko's patch I propose that we pass FNM_PATHNAME to 
> fnmatch(9),
> so that the matching is indeed consistent with glob(3) / shell glob-ing rules
> for filesystem paths.
>
> --
> Andriy Gapon
>
>
>
Absolutely yes. Any kind of rule based matching should default to
matching full strings. The rule syntax should then offer options to
narrow down the matching to a specific part(s) of the matched strings.

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

Re: troubles with buildworld/sendmail/sasl/clang

2013-03-18 Thread Kimmo Paasiala 
On Mon, Mar 18, 2013 at 1:03 PM, Beat Siegenthaler
 wrote:
> Hi all,
>
> since some days i try to "make buildworld", but have some errors in
> sendmail.
> The make conf is not changed since years (in this case) . Adding
> NO_WERROR= in src.conf helps, but i think it is not the optimal solution?
>
> # SASL (cyrus-sasl v2) sendmail build flags...
> SENDMAIL_CFLAGS+=-I/usr/local/include -DSASL=2
> SENDMAIL_LDFLAGS+=-L/usr/local/lib
> SENDMAIL_LDADD+=-lsasl2
> SENDMAIL_CFLAGS+= -D_FFR_SMTP_SSL
>
> SENDMAIL_MC = /etc/mail/xyz.mc
> WITH_SSL_AND_PLAINTEXT=yes # for imaps and cclient
>
> ==src.conf===
>
> CC=clang
> CXX=clang++
> CPP=clang-cpp
> # This setting to build world without -Werror:
> # NO_WERROR=
> # This setting to build kernel without -Werror:
> # WERROR=
>
> =buildworld===
>
> /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8:
> error: incompatible pointer types passing 'void ()' to parameter of type
> 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)'
> [-Werror,-Wincompatible-pointer-types]
>getsasldata, NULL, XS_AUTH);
>^~~
> /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: 
> note:
> passing argument to parameter here
> extern int  reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void
> (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int));
>^
> /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from
> macro '__P'
> #define __P(protos) protos  /* full-blown ANSI C */
> ^
> 3 errors generated.
> *** [usersmtp.o] Error code 1
> 1 error
> *** [all] Error code 2
> 1 error
> *** [usr.sbin.all__D] Error code 2
> 1 error
> *** [everything] Error code 2
> 1 error
> *** [buildworld] Error code 2
> 1 error
>
> regards
> beat


I can not help with the error but I really have to make this question:
Does FreeBSD really have to support pre-ANSI C compilers in 2013?

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

Re: CLANG and -fstack-protector

2013-02-17 Thread Kimmo Paasiala 
On Wed, Feb 13, 2013 at 4:22 AM, Dmitry Marakasov  wrote:
> * Kimmo Paasiala (kpaas...@gmail.com) wrote:
>
>> Does the -fstack-protector option work on CLANG 3.1 and 3.2?
>>
>> There is thread on FreeBSD forums about the stack protector and ports
>> and I'm wondering if it's possible to use the -fstack-protector option
>> with CLANG.
>>
>> http://forums.freebsd.org/showthread.php?t=36927
>
> You might be interested in this patch:
>
> https://github.com/AMDmi3/freebsd-ports-mk/compare/master...stack-protector
>
> afaik, in prior discussion some years ago an issue was mentioned that
> some ports don't build with stack-protector, so I suggested to introduce
> STACK_PROTECTOR_SAFE/_UNSAFE knobs similar to what we have for
> MAKE_JOBS_SAFE_/_UNSAFE (we might actually only need
> STACK_PROTECTOR_UNSAFE, as unlike MAKE_JOBS, build errors caused by
> enabling stack protector are not transient, so we can have an exp-run
> to just mark all uncompatible ports and consider all others compatible).
>
> If there's interest in this, I can refresh the patch and submit it.
>

Yes, this is very much what I had in mind. Please submit it :)

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

Re: ports include /etc/src.conf? i.e. graphics/libfpx

2013-02-13 Thread Kimmo Paasiala 
On Wed, Feb 13, 2013 at 3:33 PM, Tom Evans  wrote:
> On Wed, Feb 13, 2013 at 12:30 PM, Yamaya Takashi
>  wrote:
>> On 2013/02/13 19:08, O. Hartmann wrote:
>>> Setting only base system source compiler optins in /etc/src.conf, for
>>> instance
>>>
>>> #
>>> CXXFLAGS+=  -stdlib=libc++
>>> CXXFLAGS+=  -std=c++11
>>>
>>>
>>> which do NOT appear in /etc/make.conf, make building port
>>> grahpics/libfpx complaining about unrecognized compiler options.
>>>
>>> As far a sI know, /etc/src.conf is ONLY for building the source tree of
>>> the operating system and make.conf is supposed to contain all stuff
>>> necessary for compiling both world and ports, but /etc/src.conf is world
>>> only.
>>>
>>> Am I wrong?
>>>
>>> Oliver
>>>
>> Yes.
>> Because files/Makefile.bsd includes ,
>> /etc/src.conf is included.
>>
>>
>
> src.conf(5) says:
>
>   The only purpose of src.conf is to control the compilation of the FreeBSD
>   source code, which is usually located in /usr/src.
>
> Cheers
>
> Tom

If this is taken literally then could it be said that ports that use
bsd.lib.mk are broken because they are using makefile includes from
the source tree?

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

Re: CLANG and -fstack-protector

2013-02-07 Thread Kimmo Paasiala 
On Thu, Feb 7, 2013 at 11:06 PM, Dimitry Andric  wrote:
> On 2013-02-07 20:42, Kimmo Paasiala wrote:
>>
>> Does the -fstack-protector option work on CLANG 3.1 and 3.2?
>
>
> Yes, it works with both clang and gcc.
>

Good to know thank you!

>
>> There is thread on FreeBSD forums about the stack protector and ports
>> and I'm wondering if it's possible to use the -fstack-protector option
>> with CLANG.
>>
>> http://forums.freebsd.org/showthread.php?t=36927
>
>
> That thread seems to be full of confusion. :-)  The base system is mostly
> built with -fstack-protector, except for the ia64, arm and mips arches,
> and for some specific cases where it is not necessary, or unwanted.

I was aware of the base system being built with the stack protector on
systems where it makes sense.

>
> Ports are largely independent of the base system, and their compilation
> flags are different from port to port.  You could set -fstack-protector
> for your ports in either make.conf or ports.conf, if you wanted.

Is there any work being done to provide an optional Makefile knob
(WITH_STACK_PROTECTOR ?) to turn on -fstack-protector for ports that
install network services (or other critical code)? I'd bet such
feature would be popular.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CLANG and -fstack-protector

2013-02-07 Thread Kimmo Paasiala 
Hello,

Does the -fstack-protector option work on CLANG 3.1 and 3.2?

There is thread on FreeBSD forums about the stack protector and ports
and I'm wondering if it's possible to use the -fstack-protector option
with CLANG.

http://forums.freebsd.org/showthread.php?t=36927

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

2013-01-16 Thread Kimmo Paasiala 
On Thu, Dec 27, 2012 at 11:42 PM, Phil Kulin  wrote:
> 2012/12/26 Kimmo Paasiala :
>
>> I've revised the patch again and updated it at gihub,
>> https://gist.github.com/4362018.  It can now be applied at top level
>> of sources (/usr/src typically). It now does the deconfiguration in
>> reverse order of the configuration, meaning the aliases configured
>> with ipv6_addrs_IF are removed before the ones configured with
>> ifconfig_IF_aliasN="inet6 ...".
>
> Adapted for FreeBSD 8.2, works fine:
>
> --- network.subr.orig   2011-02-17 05:19:39.0 +0300
> +++ network.subr2012-12-28 00:46:38.0 +0400
> @@ -312,6 +312,12 @@ afexists()
>  #  1 otherwise.
>  ipv6if()
>  {
> +   # Test for $ipv6_addrs_IF. If it exists then the
> +   # interface should be configured for IPv6
> +   _tmpargs=$(get_if_var $_if ipv6_addrs_IF)
> +   if [ -n "${_tmpargs}" ]; then
> +   return 0
> +   fi
> if ! checkyesno ipv6_enable; then
> return 1
> fi
> @@ -948,7 +954,12 @@ network6_interface_setup()
> rtsol_interface=no
> ifconfig $i inet6 ${ipv6_ifconfig} alias
> fi
> -
> +   ipv6_addrs=`get_if_var $i ipv6_addrs_IF`
> +   if [ -n "${ipv6_addrs}" ]; then
> +   rtsol_available=no
> +   rtsol_interface=no
> +   ipv6_addrs_common ${i} alias
> +   fi
> # Wireless NIC cards are virtualized through the wlan 
> interface
> if ! is_wired_interface ${i}; then
> case "${i}" in
> @@ -1178,3 +1189,39 @@ network6_getladdr()
> esac
> done
>  }
> +
> +ipv6_addrs_common()
> +{
> +   local _ret _if _action _ip6prefix _ip6prefixes
> +   local _ip6addr _prefixlen
> +   local _range _ip6net _ip6low _ip6high
> +   _ret=1
> +   _if=$1
> +   _action=$2
> +   # get the prefixes from ipv6_addrs_IF variable
> +   _ip6prefixes=`get_if_var $_if ipv6_addrs_IF`
> +   for _ip6prefix in ${_ip6prefixes}; do
> +   _ip6addr=${_ip6prefix%%/*}
> +   _prefixlen=${_ip6prefix##*/}
> +   _range=${_ip6addr##*:}
> +   _ip6net=${_ip6addr%:*}
> +   _ip6low=${_range%-*}
> +   _ip6high=${_range#*-}
> +   # If deleting an alias, set _prefixlen to null string.
> +   if [ "${_action}" = "-alias" ]; then
> +   _prefixlen=""
> +   else
> +   _prefixlen="prefixlen $_prefixlen"
> +   fi
> +   _ip6high=$(("0x${_ip6high}"))
> +   _ip6count=$(("0x${_ip6low}"))
> +   while [ "${_ip6count}" -le "${_ip6high}" ]; do
> +   # Re-uses the _ip6addr variable from above
> +   _ip6addr=$(printf "%x" "${_ip6count}")
> +   eval "ifconfig ${_if} inet6
> ${_ip6net}:${_ip6addr} ${_prefixlen} ${_action}"
> +   _ip6count=$((${_ip6count}+1))
> +   _ret=0
> +   done
> +   done
> +   return $_ret
> +}
>
>
> --
> Non nobis Domine non nobis sed Nomini Tuo da gloriam
> Phil Kulin

I don't have an 8.X system to test but I guess it's fine.

Any more interest in this? I'd love to see this added, not because I
wrote it but because I want to contribute in any way I can.

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

Re: base system: remnant old files not covered by "make delete-old-files"

2012-12-26 Thread Kimmo Paasiala 
On Wed, Dec 26, 2012 at 6:20 PM, O. Hartmann
 wrote:
> Am 12/26/12 12:58, schrieb Sergey Kandaurov:
>> On 26 December 2012 15:49, O. Hartmann  wrote:
>>> I figured out that my system is somekind of "polluted" by remnant old files.
>>>
>>> I do installworld on a regular basis and I do it like suggested in the
>>> handbook. I also regularyly do make delete-old-XXX in /usr/src.
>>>
>>> Well, now I figured out that there are some remnants in several system
>>> folders, for instance
>>>
>>> /usr/bin/ncplogout
>>> /usr/bin/ncplist (and some more, but last updated Oct, 17th)
>>>
>>> or
>>>
>>> /usr/bin/smbutil
>>>
>>> or
>>>
>>> /usr/sbin/mount_nwfs
>>> /usr/sbin/mount_portalfs
>>> /usr/sbin/mount_smbfs (last update around the 16. Oktober)
>>>
>>> or
>>>
>>>
>>> /sbin/mount_ntfs
>>>
>>> Is this by intention or ist this an accident?
>>>
>>> I guess the binaries will by out of sync with the kernel if they remain
>>> unchanged.
>>>
>>
>> This is an intentional leftover from
>> http://svn.freebsd.org/changeset/base/241629
>>
>> On 17.10.12 20:50, Attilio Rao wrote:
>> "For the moment we should not move the files yet into
>> ObsoleteFiles.inc. This is done because all the FS removed code will
>> make it into ObsoleteFiles.inc into a separate pass, in 3-4 months,
>> giving people time to possibly fix and re-link a filesystem."
>>
>
>
> ah, I see. So removing those files manually will not harm the system if
> those filesystems were never used ina any way?
>
>
> Oliver
>

You can see which binaries in
/bin,/sbin,/usr/bin,/usr/sbin,/libexec,/usr/libexec are obsolete by
doing 'make installworld DESTDIR=/some/directory' and comparing your
installed binaries against the directory tree you just created at
/some/directory.

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

2012-12-26 Thread Kimmo Paasiala 
On Mon, Dec 24, 2012 at 6:07 AM, Kimmo Paasiala  wrote:
> On Sat, Dec 22, 2012 at 7:49 PM, Łukasz Wąsikowski
>  wrote:
>> W dniu 2012-12-22 18:14, Ben Morrow pisze:
>>> Quoth =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= :
>>>> W dniu 2012-12-22 04:41, Kimmo Paasiala pisze:
>>>>
>>>>> Yeah, this is problem in network.subr. An interface is not recognized
>>>>> as IPv6 capable if the interface is not in "ipv6_network_interfaces"
>>>>> and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it
>>>>> "just works" because the interface is always assumed to be IPv4
>>>>> capable.
>>>>
>>>> Ok, I used ifconfig_em0_ipv6="up" and it worked. So it looks like this:
>>>
>>> The documented way to do this is to just set the link-local address in
>>> ifconfig_IF_ipv6, since an interface is required to have a link-local
>>> address. Either configure an fe80:: address explicitly or set
>>>
>>> ifconfig_em0_ipv6="inet6 auto_linklocal"
>>>
>>> Alternatively, if you set ipv6_activate_all_interfaces all interfaces
>>> will be considered IPv6-capable.
>>
>> link-local address is assigned by default, even with ifconfig_IF_ipv6="up".
>>
>> root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf ; ifconfig
>> em0 | grep -E '^[[:space:]]*inet6' | head -2
>> hostname="freebsd"
>> ifconfig_em0="up"
>> ipv4_addrs_em0="192.168.168.20-24/24"
>> defaultrouter="192.168.168.1"
>> ipv6_network_interfaces="em0"
>> ipv6_defaultrouter="2001:6a0:1cb::"
>> ifconfig_em0_ipv6="up"
>> ipv6_addrs_em0="2001:6a0:1cb::1-e/128"
>> sshd_enable="YES"
>> dumpdev="NO"
>> named_enable="YES"
>> inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1
>> inet6 2001:6a0:1cb::1 prefixlen 128
>>
>> Of course using "inet6 auto_linklocal" instead of "up" seems a better
>> way to do it, thank you for this tip.
>>
>> --
>> best regards,
>> Lukasz Wasikowski
>
>
> I have put up the patch at github as:
>
> https://gist.github.com/4362018
>
> This version should work with just the ipv6_addrs_IF in rc.conf(5). I
> changed the detection of ipv6 interfaces so that just having the
> ipv6_addrs_IF line is enough.
>
> -Kimmo

I've revised the patch again and updated it at gihub,
https://gist.github.com/4362018.  It can now be applied at top level
of sources (/usr/src typically). It now does the deconfiguration in
reverse order of the configuration, meaning the aliases configured
with ipv6_addrs_IF are removed before the ones configured with
ifconfig_IF_aliasN="inet6 ...".

Also as noted in my previous message it's possible to configure all
IPv6 addresses with a single ipv6_addrs_IF line in rc.conf:

ipv6_addrs_re0="2001:db8::::1-4/64"


I consider this version of the patch pretty much completed work. It
applies cleanly to HEAD version r244694 and I don't see why it
wouldn't work in HEAD as well.

Now, is there any interest in seeing this feature as part of future
versions of FreeBSD? Could it be incorporated to HEAD and then MFC'ed
to 9-STABLE  if it turns out it's seen as a useful feature?

Regards,

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

2012-12-23 Thread Kimmo Paasiala 
On Sat, Dec 22, 2012 at 7:49 PM, Łukasz Wąsikowski
 wrote:
> W dniu 2012-12-22 18:14, Ben Morrow pisze:
>> Quoth =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= :
>>> W dniu 2012-12-22 04:41, Kimmo Paasiala pisze:
>>>
>>>> Yeah, this is problem in network.subr. An interface is not recognized
>>>> as IPv6 capable if the interface is not in "ipv6_network_interfaces"
>>>> and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it
>>>> "just works" because the interface is always assumed to be IPv4
>>>> capable.
>>>
>>> Ok, I used ifconfig_em0_ipv6="up" and it worked. So it looks like this:
>>
>> The documented way to do this is to just set the link-local address in
>> ifconfig_IF_ipv6, since an interface is required to have a link-local
>> address. Either configure an fe80:: address explicitly or set
>>
>> ifconfig_em0_ipv6="inet6 auto_linklocal"
>>
>> Alternatively, if you set ipv6_activate_all_interfaces all interfaces
>> will be considered IPv6-capable.
>
> link-local address is assigned by default, even with ifconfig_IF_ipv6="up".
>
> root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf ; ifconfig
> em0 | grep -E '^[[:space:]]*inet6' | head -2
> hostname="freebsd"
> ifconfig_em0="up"
> ipv4_addrs_em0="192.168.168.20-24/24"
> defaultrouter="192.168.168.1"
> ipv6_network_interfaces="em0"
> ipv6_defaultrouter="2001:6a0:1cb::"
> ifconfig_em0_ipv6="up"
> ipv6_addrs_em0="2001:6a0:1cb::1-e/128"
> sshd_enable="YES"
> dumpdev="NO"
> named_enable="YES"
> inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1
> inet6 2001:6a0:1cb::1 prefixlen 128
>
> Of course using "inet6 auto_linklocal" instead of "up" seems a better
> way to do it, thank you for this tip.
>
> --
> best regards,
> Lukasz Wasikowski


I have put up the patch at github as:

https://gist.github.com/4362018

This version should work with just the ipv6_addrs_IF in rc.conf(5). I
changed the detection of ipv6 interfaces so that just having the
ipv6_addrs_IF line is enough.

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

2012-12-22 Thread Kimmo Paasiala 
On Sat, Dec 22, 2012 at 4:25 PM, Łukasz Wąsikowski
 wrote:
> W dniu 2012-12-22 04:41, Kimmo Paasiala pisze:
>
>>>> It looks like the reason for the difference to ipv4_addrs_IF is that
>>>> the "alias" parameter for ifconfig(8) operates differently for IPv6
>>>> addresses, the first address of an interface can't be added with
>>>> "alias", for IPv4 it does not care. I'll have to dig deeper but that's
>>>> what the problem seems to be.
>>>>
>>>> -Kimmo
>>>
>>> The 'alias' parameter of ifconfig(8) is not the problem on the first
>>> ipv6 address, I have verified that. However, there's probably
>>> something in network.subr or /etc/rc.d/netif that I have overlooked
>>> and causes my code to be skipped if there's no ifconfig_IF_ipv6
>>> variable defined in rc.conf(5).
>>>
>>> -Kimmo
>>
>> Yeah, this is problem in network.subr. An interface is not recognized
>> as IPv6 capable if the interface is not in "ipv6_network_interfaces"
>> and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it
>> "just works" because the interface is always assumed to be IPv4
>> capable.
>
> Ok, I used ifconfig_em0_ipv6="up" and it worked. So it looks like this:
>
> ipv6_activate_all_interfaces="NO"
> ipv6_network_interfaces="em0"
> ifconfig_em0_ipv6="up"
> ipv6_addrs_em0="2001:6a0:1cb::1-ff/64"
> ipv6_defaultrouter="2001:6a0:1cb::"
>
> Good job, thank you! :)
>
> --
> best regards,
> Lukasz Wasikowski

I'm looking into fixing the issue so you could just have the
ipv6_addrs_em0 line in rc.conf. However I don't want to flood the PR
and this mailing list with different versions of the patch. I want to
get it right next time. Stay tuned.

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

2012-12-21 Thread Kimmo Paasiala 
On Sat, Dec 22, 2012 at 5:09 AM, Kimmo Paasiala  wrote:
> On Sat, Dec 22, 2012 at 3:19 AM, Kimmo Paasiala  wrote:
>> On Sat, Dec 22, 2012 at 1:38 AM, Łukasz Wąsikowski
>>  wrote:
>>> W dniu 2012-12-21 13:23, Kimmo Paasiala pisze:
>>>> On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala  wrote:
>>>>> On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker  wrote:
>>>>>> On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote:
>>>>>>> A question related to this for those who have been doing work on the
>>>>>>> rc(8) scripts. Can I assume that /usr/bin is available when
>>>>>>> network.subr functions are used? Doing calculations on hexadecimal
>>>>>>> numbers is going to be very awkward if I can't use for example bc(1).
>>>>>>
>>>>>> You cannot assume that /usr/bin is available when setting up the
>>>>>> network. It may be that /usr is mounted via NFS.
>>>>>>
>>>>>> You can use hexadecimal numbers (prefixed with 0x) in $((...))
>>>>>> expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can
>>>>>> use; in older versions you can use hexdigit and hexprint from
>>>>>> network.subr.
>>>>>>
>>>>>> --
>>>>>> Jilles Tjoelker
>>>>>
>>>>> Thanks, I've rewitten my patch to support ranges. It is attached in
>>>>> this message.
>>>>>
>>>>> Again it's against a very recent 9-STABLE, I still haven't found time
>>>>> to see if it applies to CURRENT.
>>>>>
>>>>> It does allow you to do crazy stuff like
>>>>>
>>>>> ipv6_addrs_re0="2001:db8::::1-/64"
>>>>>
>>>>> However I didn't find anything to limit the number of aliases in the
>>>>> ipv4 version of the function either.
>>>>>
>>>>> Please test it :)
>>>>>
>>>>>
>>>>> Then a question about the PR
>>>>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I
>>>>> attach this new patch to it? The submit follow up -button fires up my
>>>>> email client and I'm not so sure how to submit a new patch for the PR
>>>>> in an email in such a way that it appears properly formatted in the
>>>>> PR.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Kimmo Paasiala
>>>>
>>>> PR updated with the new patch.
>>>
>>> Your patch applied cleanly, but it's not working or I am doing something
>>> wrong.
>>>
>>> root@freebsd:~ # uname -a
>>> FreeBSD freebsd 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1 r244567: Fri
>>> Dec 21 23:57:28 CET 2012 root@freebsd:/usr/obj/usr/src/sys/GENERIC
>>> amd64
>>>
>>> root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf
>>> hostname="freebsd"
>>> ifconfig_em0="up"
>>> ipv4_addrs_em0="192.168.168.20-24/24"
>>> defaultrouter="192.168.168.1"
>>> ipv6_activate_all_interfaces="YES"
>>> ipv6_addrs_em0="2001:6a0:1cb::1-6/64"
>>> ipv6_defaultrouter="2001:6a0:1cb::"
>>> sshd_enable="YES"
>>> dumpdev="NO"
>>> named_enable="YES"
>>>
>>> root@freebsd:~ # ifconfig
>>> em0: flags=8843 metric 0 mtu 1500
>>> options=9b
>>> ether 08:00:27:02:83:71
>>> inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1
>>> inet 192.168.168.20 netmask 0xff00 broadcast 192.168.168.255
>>> inet 192.168.168.21 netmask 0x broadcast 192.168.168.21
>>> inet 192.168.168.22 netmask 0x broadcast 192.168.168.22
>>> inet 192.168.168.23 netmask 0x broadcast 192.168.168.23
>>> inet 192.168.168.24 netmask 0x broadcast 192.168.168.24
>>> nd6 options=21
>>> media: Ethernet autoselect (1000baseT )
>>> status: active
>>> lo0: flags=8049 metric 0 mtu 16384
>>> options=63
>>> inet6 ::1 prefixlen 128
>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
>>> inet 127.0.0.1 netmask 0xff00
>>> nd6 options=21
>>>
>>> -

Re: ipv6_addrs_IF aliases in rc.conf(5)

2012-12-21 Thread Kimmo Paasiala 
On Sat, Dec 22, 2012 at 3:19 AM, Kimmo Paasiala  wrote:
> On Sat, Dec 22, 2012 at 1:38 AM, Łukasz Wąsikowski
>  wrote:
>> W dniu 2012-12-21 13:23, Kimmo Paasiala pisze:
>>> On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala  wrote:
>>>> On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker  wrote:
>>>>> On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote:
>>>>>> A question related to this for those who have been doing work on the
>>>>>> rc(8) scripts. Can I assume that /usr/bin is available when
>>>>>> network.subr functions are used? Doing calculations on hexadecimal
>>>>>> numbers is going to be very awkward if I can't use for example bc(1).
>>>>>
>>>>> You cannot assume that /usr/bin is available when setting up the
>>>>> network. It may be that /usr is mounted via NFS.
>>>>>
>>>>> You can use hexadecimal numbers (prefixed with 0x) in $((...))
>>>>> expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can
>>>>> use; in older versions you can use hexdigit and hexprint from
>>>>> network.subr.
>>>>>
>>>>> --
>>>>> Jilles Tjoelker
>>>>
>>>> Thanks, I've rewitten my patch to support ranges. It is attached in
>>>> this message.
>>>>
>>>> Again it's against a very recent 9-STABLE, I still haven't found time
>>>> to see if it applies to CURRENT.
>>>>
>>>> It does allow you to do crazy stuff like
>>>>
>>>> ipv6_addrs_re0="2001:db8::::1-/64"
>>>>
>>>> However I didn't find anything to limit the number of aliases in the
>>>> ipv4 version of the function either.
>>>>
>>>> Please test it :)
>>>>
>>>>
>>>> Then a question about the PR
>>>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I
>>>> attach this new patch to it? The submit follow up -button fires up my
>>>> email client and I'm not so sure how to submit a new patch for the PR
>>>> in an email in such a way that it appears properly formatted in the
>>>> PR.
>>>>
>>>> Regards,
>>>>
>>>> Kimmo Paasiala
>>>
>>> PR updated with the new patch.
>>
>> Your patch applied cleanly, but it's not working or I am doing something
>> wrong.
>>
>> root@freebsd:~ # uname -a
>> FreeBSD freebsd 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1 r244567: Fri
>> Dec 21 23:57:28 CET 2012 root@freebsd:/usr/obj/usr/src/sys/GENERIC
>> amd64
>>
>> root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf
>> hostname="freebsd"
>> ifconfig_em0="up"
>> ipv4_addrs_em0="192.168.168.20-24/24"
>> defaultrouter="192.168.168.1"
>> ipv6_activate_all_interfaces="YES"
>> ipv6_addrs_em0="2001:6a0:1cb::1-6/64"
>> ipv6_defaultrouter="2001:6a0:1cb::"
>> sshd_enable="YES"
>> dumpdev="NO"
>> named_enable="YES"
>>
>> root@freebsd:~ # ifconfig
>> em0: flags=8843 metric 0 mtu 1500
>> options=9b
>> ether 08:00:27:02:83:71
>> inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1
>> inet 192.168.168.20 netmask 0xff00 broadcast 192.168.168.255
>> inet 192.168.168.21 netmask 0x broadcast 192.168.168.21
>> inet 192.168.168.22 netmask 0x broadcast 192.168.168.22
>> inet 192.168.168.23 netmask 0x broadcast 192.168.168.23
>> inet 192.168.168.24 netmask 0x broadcast 192.168.168.24
>> nd6 options=21
>> media: Ethernet autoselect (1000baseT )
>> status: active
>> lo0: flags=8049 metric 0 mtu 16384
>> options=63
>> inet6 ::1 prefixlen 128
>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
>> inet 127.0.0.1 netmask 0xff00
>> nd6 options=21
>>
>> --
>> best regards,
>> Lukasz Wasikowski
>
> You need to first add a single ipv6 address using the
> ifconfig_em0_ipv6 -syntax.
>
> ifconfig_em0_ipv6="2001:6a0:1cb::1/64"
>
> And then this should add the rest of the addresses
>
> ipv6_addrs_em0="2001:6a0:1cb::2-6/64"
>
> It looks like the reason for the difference to ipv4_addrs_IF is that
> the "alias" parameter for ifconfig(8) operates differently for IPv6
> addresses, the first address of an interface can't be added with
> "alias", for IPv4 it does not care. I'll have to dig deeper but that's
> what the problem seems to be.
>
> -Kimmo

The 'alias' parameter of ifconfig(8) is not the problem on the first
ipv6 address, I have verified that. However, there's probably
something in network.subr or /etc/rc.d/netif that I have overlooked
and causes my code to be skipped if there's no ifconfig_IF_ipv6
variable defined in rc.conf(5).

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

2012-12-21 Thread Kimmo Paasiala 
On Sat, Dec 22, 2012 at 1:38 AM, Łukasz Wąsikowski
 wrote:
> W dniu 2012-12-21 13:23, Kimmo Paasiala pisze:
>> On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala  wrote:
>>> On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker  wrote:
>>>> On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote:
>>>>> A question related to this for those who have been doing work on the
>>>>> rc(8) scripts. Can I assume that /usr/bin is available when
>>>>> network.subr functions are used? Doing calculations on hexadecimal
>>>>> numbers is going to be very awkward if I can't use for example bc(1).
>>>>
>>>> You cannot assume that /usr/bin is available when setting up the
>>>> network. It may be that /usr is mounted via NFS.
>>>>
>>>> You can use hexadecimal numbers (prefixed with 0x) in $((...))
>>>> expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can
>>>> use; in older versions you can use hexdigit and hexprint from
>>>> network.subr.
>>>>
>>>> --
>>>> Jilles Tjoelker
>>>
>>> Thanks, I've rewitten my patch to support ranges. It is attached in
>>> this message.
>>>
>>> Again it's against a very recent 9-STABLE, I still haven't found time
>>> to see if it applies to CURRENT.
>>>
>>> It does allow you to do crazy stuff like
>>>
>>> ipv6_addrs_re0="2001:db8::::1-/64"
>>>
>>> However I didn't find anything to limit the number of aliases in the
>>> ipv4 version of the function either.
>>>
>>> Please test it :)
>>>
>>>
>>> Then a question about the PR
>>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I
>>> attach this new patch to it? The submit follow up -button fires up my
>>> email client and I'm not so sure how to submit a new patch for the PR
>>> in an email in such a way that it appears properly formatted in the
>>> PR.
>>>
>>> Regards,
>>>
>>> Kimmo Paasiala
>>
>> PR updated with the new patch.
>
> Your patch applied cleanly, but it's not working or I am doing something
> wrong.
>
> root@freebsd:~ # uname -a
> FreeBSD freebsd 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1 r244567: Fri
> Dec 21 23:57:28 CET 2012 root@freebsd:/usr/obj/usr/src/sys/GENERIC
> amd64
>
> root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf
> hostname="freebsd"
> ifconfig_em0="up"
> ipv4_addrs_em0="192.168.168.20-24/24"
> defaultrouter="192.168.168.1"
> ipv6_activate_all_interfaces="YES"
> ipv6_addrs_em0="2001:6a0:1cb::1-6/64"
> ipv6_defaultrouter="2001:6a0:1cb::"
> sshd_enable="YES"
> dumpdev="NO"
> named_enable="YES"
>
> root@freebsd:~ # ifconfig
> em0: flags=8843 metric 0 mtu 1500
> options=9b
> ether 08:00:27:02:83:71
> inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1
> inet 192.168.168.20 netmask 0xff00 broadcast 192.168.168.255
> inet 192.168.168.21 netmask 0x broadcast 192.168.168.21
> inet 192.168.168.22 netmask 0x broadcast 192.168.168.22
> inet 192.168.168.23 netmask 0x broadcast 192.168.168.23
> inet 192.168.168.24 netmask 0x broadcast 192.168.168.24
> nd6 options=21
> media: Ethernet autoselect (1000baseT )
> status: active
> lo0: flags=8049 metric 0 mtu 16384
> options=63
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> inet 127.0.0.1 netmask 0xff00
> nd6 options=21
>
> --
> best regards,
> Lukasz Wasikowski

You need to first add a single ipv6 address using the
ifconfig_em0_ipv6 -syntax.

ifconfig_em0_ipv6="2001:6a0:1cb::1/64"

And then this should add the rest of the addresses

ipv6_addrs_em0="2001:6a0:1cb::2-6/64"

It looks like the reason for the difference to ipv4_addrs_IF is that
the "alias" parameter for ifconfig(8) operates differently for IPv6
addresses, the first address of an interface can't be added with
"alias", for IPv4 it does not care. I'll have to dig deeper but that's
what the problem seems to be.

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

2012-12-21 Thread Kimmo Paasiala 
On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala  wrote:
> On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker  wrote:
>> On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote:
>>> A question related to this for those who have been doing work on the
>>> rc(8) scripts. Can I assume that /usr/bin is available when
>>> network.subr functions are used? Doing calculations on hexadecimal
>>> numbers is going to be very awkward if I can't use for example bc(1).
>>
>> You cannot assume that /usr/bin is available when setting up the
>> network. It may be that /usr is mounted via NFS.
>>
>> You can use hexadecimal numbers (prefixed with 0x) in $((...))
>> expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can
>> use; in older versions you can use hexdigit and hexprint from
>> network.subr.
>>
>> --
>> Jilles Tjoelker
>
> Thanks, I've rewitten my patch to support ranges. It is attached in
> this message.
>
> Again it's against a very recent 9-STABLE, I still haven't found time
> to see if it applies to CURRENT.
>
> It does allow you to do crazy stuff like
>
> ipv6_addrs_re0="2001:db8::::1-/64"
>
> However I didn't find anything to limit the number of aliases in the
> ipv4 version of the function either.
>
> Please test it :)
>
>
> Then a question about the PR
> (http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I
> attach this new patch to it? The submit follow up -button fires up my
> email client and I'm not so sure how to submit a new patch for the PR
> in an email in such a way that it appears properly formatted in the
> PR.
>
> Regards,
>
> Kimmo Paasiala

PR updated with the new patch.

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

2012-12-20 Thread Kimmo Paasiala 
On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker  wrote:
> On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote:
>> A question related to this for those who have been doing work on the
>> rc(8) scripts. Can I assume that /usr/bin is available when
>> network.subr functions are used? Doing calculations on hexadecimal
>> numbers is going to be very awkward if I can't use for example bc(1).
>
> You cannot assume that /usr/bin is available when setting up the
> network. It may be that /usr is mounted via NFS.
>
> You can use hexadecimal numbers (prefixed with 0x) in $((...))
> expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can
> use; in older versions you can use hexdigit and hexprint from
> network.subr.
>
> --
> Jilles Tjoelker

Thanks, I've rewitten my patch to support ranges. It is attached in
this message.

Again it's against a very recent 9-STABLE, I still haven't found time
to see if it applies to CURRENT.

It does allow you to do crazy stuff like

ipv6_addrs_re0="2001:db8::::1-/64"

However I didn't find anything to limit the number of aliases in the
ipv4 version of the function either.

Please test it :)


Then a question about the PR
(http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I
attach this new patch to it? The submit follow up -button fires up my
email client and I'm not so sure how to submit a new patch for the PR
in an email in such a way that it appears properly formatted in the
PR.

Regards,

Kimmo Paasiala
Index: network.subr
===
--- network.subr(revision 244523)
+++ network.subr(working copy)
@@ -562,6 +562,7 @@
fi
 
ifalias_up ${_if} inet6 && _ret=0
+   ipv6_addrs_common ${_if} alias && _ret=0
ipv6_prefix_hostid_addr_common ${_if} alias && _ret=0
ipv6_accept_rtadv_up ${_if} && _ret=0
 
@@ -684,6 +685,49 @@
return $_ret
 }
 
+
+ipv6_addrs_common()
+{
+   local _ret _if _action _ip6prefix _ip6prefixes
+   local _ip6addr _prefixlen
+   local _range _ip6net _ip6low _ip6high
+   _ret=1
+   _if=$1
+   _action=$2
+
+# get the prefixes from ipv6_addrs_IF variable
+   _ip6prefixes=`get_if_var $_if ipv6_addrs_IF`
+   for _ip6prefix in ${_ip6prefixes}; do
+   _ip6addr=${_ip6prefix%%/*}
+   _prefixlen=${_ip6prefix##*/}
+   _range=${_ip6addr##*:}
+   _ip6net=${_ip6addr%:*}
+   _ip6low=${_range%-*}
+   _ip6high=${_range#*-}
+
+# If deleting an alias, set _prefixlen to null string.
+   if [ "${_action}" = "-alias" ]; then
+   _prefixlen=""
+   else
+   _prefixlen="prefixlen $_prefixlen"
+   fi
+
+   _ip6high=$(("0x${_ip6high}"))
+   _ip6count=$(("0x${_ip6low}"))
+   while [ "${_ip6count}" -le "${_ip6high}"  ]; do
+# Re-uses the _ip6addr variable from above
+   _ip6addr=$(printf "%x" "${_ip6count}")
+   eval "ifconfig ${_if} inet6 ${_ip6net}:${_ip6addr} 
${_prefixlen} ${_action}"
+   _ip6count=$((${_ip6count}+1))
+   _ret=0
+   done
+   done
+
+   return $_ret
+}
+
+
+
 # ifalias_up if af
 #  Configure aliases for network interface $if.
 #  It returns 0 if at least one alias was configured or
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ipv6_addrs_IF aliases in rc.conf(5)

2012-12-20 Thread Kimmo Paasiala 
On Wed, Dec 19, 2012 at 11:47 PM, Kimmo Paasiala  wrote:
> On Wed, Dec 19, 2012 at 3:46 PM, Łukasz Wąsikowski
>  wrote:
>> W dniu 2012-12-19 07:14, Kimmo Paasiala pisze:
>>
>>>> I wrote a small patch for /etc/network.subr to add support for
>>>> ipv6_addrs_IF aliases in rc.conf(5) to match the already existing
>>>> ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6
>>>> aliases can be written like:
>>
>> [...]
>>
>>> Did anyone try my patch? I thought it would be nice to have the
>>> ipv6_addrs_IF syntax supported to complement the existing
>>> ipv4_addrs_IF alias syntax.
>>
>> Can I use range syntax in it like in ipv4? I mean something like:
>>
>> ipv4_addrs_lagg0="x.x.x.10-30/22"
>>
>> That feature would be very nice to have for ipv6.
>>
>> --
>> best regards,
>> Lukasz Wasikowski
>
> I have to admit I overlooked the possibility to use ranges like that.
> It doesn't look too hard to add that feature as well for ipv6 aliases
> using the existing code for ipv4 aliases. I'll prepare a new patch and
> update the PR when I have it working.
>
> -Kimmo

A question related to this for those who have been doing work on the
rc(8) scripts. Can I assume that /usr/bin is available when
network.subr functions are used? Doing calculations on hexadecimal
numbers is going to be very awkward if I can't use for example bc(1).

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

Re: [HEADSUP] zfs root pool mounting

2012-12-19 Thread Kimmo Paasiala 
On Wed, Nov 28, 2012 at 8:35 PM, Andriy Gapon  wrote:
>
> Recently some changes were made to how a root pool is opened for root 
> filesystem
> mounting.  Previously the root pool had to be present in zpool.cache.  Now it 
> is
> automatically discovered by probing available GEOM providers.
> The new scheme is believed to be more flexible.  For example, it allows to 
> prepare
> a new root pool at one system, then export it and then boot from it on a new
> system without doing any extra/magical steps with zpool.cache.  It could also 
> be
> convenient after zpool split and in some other situations.
>
> The change was introduced via multiple commits, the latest relevant revision 
> in
> head is r243502.  The changes are partially MFC-ed, the remaining parts are
> scheduled to be MFC-ed soon.
>
> I have received a report that the change caused a problem with booting on at 
> least
> one system.  The problem has been identified as an issue in local environment 
> and
> has been fixed.  Please read on to see if you might be affected when you 
> upgrade,
> so that you can avoid any unnecessary surprises.
>
> You might be affected if you ever had a pool named the same as your current 
> root
> pool.  And you still have any disks connected to your system that belonged to 
> that
> pool (in whole or via some partitions).  And that pool was never properly
> destroyed using zpool destroy, but merely abandoned (its disks
> re-purposed/re-partitioned/reused).
>
> If all of the above are true, then I recommend that you run 'zdb -l ' 
> for
> all suspect disks and their partitions (or just all disks and partitions).  If
> this command reports at least one valid ZFS label for a disk or a partition 
> that
> do not belong to any current pool, then the problem may affect you.
>
> The best course is to remove the offending labels.
>
> If you are affected, please follow up to this email.
>
> --
> Andriy Gapon
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Hello,

What is the status of the MFC process to 9-STABLE? I'm on 9-STABLE
r244407, should I be able to boot from this ZFS pool without
zpool.cache?

zpool status
  pool: zwhitezone
 state: ONLINE
  scan: scrub repaired 0 in 0h53m with 0 errors on Sat Dec 15 23:41:09 2012
config:

NAME   STATE READ WRITE CKSUM
zwhitezone ONLINE   0 0 0
  mirror-0 ONLINE   0 0 0
label/wzdisk0  ONLINE   0 0 0
label/wzdisk1  ONLINE   0 0 0
  mirror-1 ONLINE   0 0 0
label/wzdisk2  ONLINE   0 0 0
label/wzdisk3  ONLINE   0 0 0

errors: No known data errors
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ipv6_addrs_IF aliases in rc.conf(5)

2012-12-19 Thread Kimmo Paasiala 
On Wed, Dec 19, 2012 at 3:46 PM, Łukasz Wąsikowski
 wrote:
> W dniu 2012-12-19 07:14, Kimmo Paasiala pisze:
>
>>> I wrote a small patch for /etc/network.subr to add support for
>>> ipv6_addrs_IF aliases in rc.conf(5) to match the already existing
>>> ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6
>>> aliases can be written like:
>
> [...]
>
>> Did anyone try my patch? I thought it would be nice to have the
>> ipv6_addrs_IF syntax supported to complement the existing
>> ipv4_addrs_IF alias syntax.
>
> Can I use range syntax in it like in ipv4? I mean something like:
>
> ipv4_addrs_lagg0="x.x.x.10-30/22"
>
> That feature would be very nice to have for ipv6.
>
> --
> best regards,
> Lukasz Wasikowski

I have to admit I overlooked the possibility to use ranges like that.
It doesn't look too hard to add that feature as well for ipv6 aliases
using the existing code for ipv4 aliases. I'll prepare a new patch and
update the PR when I have it working.

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

2012-12-18 Thread Kimmo Paasiala 
On Fri, Dec 7, 2012 at 12:42 PM, Kimmo Paasiala  wrote:
> Hello,
>
> I wrote a small patch for /etc/network.subr to add support for
> ipv6_addrs_IF aliases in rc.conf(5) to match the already existing
> ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6
> aliases can be written like:
>
> ipv6_addrs_re0="2001:db8::::1/64 2001:db8::::2/64"
>
> Only this syntax is supported, it's not possible to use the "prefixlen
> nn" syntax in the list.
>
> The patch is against a recent 9-STABLE, last changed rev of
> network.subr on my SVN checkout is r242187. I don't have a CURRENT
> system to test if it applies to CURRENT as well.
>
> The patch can be found attached to a PR I sent:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=174225
>
>
> I wrote this patch inspired by a question on the FreeBSD forums:
>
> http://forums.freebsd.org/showthread.php?t=36136
>
> Please test and report if it works for you :)
>
>
> Regards,
> Kimmo Paasiala

Hello,

Did anyone try my patch? I thought it would be nice to have the
ipv6_addrs_IF syntax supported to complement the existing
ipv4_addrs_IF alias syntax.

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

Re: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory.

2012-12-13 Thread Kimmo Paasiala 
On Thu, Dec 13, 2012 at 4:13 PM, Ian Lepore
 wrote:
> On Wed, 2012-12-12 at 20:52 +0200, Kimmo Paasiala wrote:
>> On Wed, Dec 12, 2012 at 6:53 PM, Ian Lepore
>>  wrote:
>> > On Wed, 2012-12-12 at 18:14 +0200, Kimmo Paasiala wrote:
>> >> Hello,
>> >>
>> >> My 9-STABLE buildworld broke in a very inexplicable way,  I was
>> >> getting an error on /usr/src/include/osreldate.h that I couldn't
>> >> figure out until I started looking at the sys/conf/newvers.sh and what
>> >> it does. It turned out that the thing that broke my buildworld was
>> >> having .git directory at the root directory of the system because I
>> >> recently started using GIT to track the configuration files.
>> >>
>> >> I added some debug echos to the newvers.sh and I found out it's
>> >> setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set
>> >> the gitdir to /.git and that seems to break the logic in newvers.sh.
>> >>
>> >> Isn't SYSDIR supposed to be set to the sys -subdirectory of the source
>> >> tree (/usr/src/sys default)?
>> >>
>> >> I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in
>> >> newvers.sh:
>> >>
>> >> SYSDIR=$(dirname $0)/..
>> >>
>> >> $0 is actually /bin/sh and not the path to newver.sh because the
>> >> newvers.sh is sourced by the Makefile in /usr/src/include instead of
>> >> executing it:
>> >>
>> >> osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh 
>> >> ${.CURDIR}/../sys/sys/param.h \
>> >> ${.CURDIR}/Makefile
>> >> @${ECHO} creating osreldate.h from newvers.sh
>> >> @MAKE=${MAKE}; \
>> >> PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
>> >> . ${.CURDIR}/../sys/conf/newvers.sh; \
>> >>
>> >> Now the question is how to fix this?
>> >>
>> >> -Kimmo
>> >
>> > Perhaps it could be handled similar to PARAMFILE, something like this in
>> > the makefile:
>> >
>> >   PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
>> >   SYSDIR=${.CURDIR}/../sys; \
>> >  . ${.CURDIR}/../sys/conf/newvers.sh; \
>> >
>> > I'm not sure if newvers.sh needs to work in ways that don't involve
>> > being invoked from that makefile rule, so to be safe it could have
>> > default handling, something like:
>> >
>> >  : ${SYSDIR:=$(dirname $0)/..}
>> >
>> > -- Ian
>> >
>> >
>>
>> Thanks, that works. Should I file a PR about this?
>>
>> -Kimmo
>
> I think that would probably be a good idea, since no committer has
> chimed in on this thread saying they're about to commit a fix.
>
> -- Ian
>
>

Submitted as misc/174422.

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

Re: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory.

2012-12-12 Thread Kimmo Paasiala 
On Wed, Dec 12, 2012 at 6:53 PM, Ian Lepore
 wrote:
> On Wed, 2012-12-12 at 18:14 +0200, Kimmo Paasiala wrote:
>> Hello,
>>
>> My 9-STABLE buildworld broke in a very inexplicable way,  I was
>> getting an error on /usr/src/include/osreldate.h that I couldn't
>> figure out until I started looking at the sys/conf/newvers.sh and what
>> it does. It turned out that the thing that broke my buildworld was
>> having .git directory at the root directory of the system because I
>> recently started using GIT to track the configuration files.
>>
>> I added some debug echos to the newvers.sh and I found out it's
>> setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set
>> the gitdir to /.git and that seems to break the logic in newvers.sh.
>>
>> Isn't SYSDIR supposed to be set to the sys -subdirectory of the source
>> tree (/usr/src/sys default)?
>>
>> I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in
>> newvers.sh:
>>
>> SYSDIR=$(dirname $0)/..
>>
>> $0 is actually /bin/sh and not the path to newver.sh because the
>> newvers.sh is sourced by the Makefile in /usr/src/include instead of
>> executing it:
>>
>> osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh ${.CURDIR}/../sys/sys/param.h 
>> \
>> ${.CURDIR}/Makefile
>> @${ECHO} creating osreldate.h from newvers.sh
>> @MAKE=${MAKE}; \
>> PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
>> . ${.CURDIR}/../sys/conf/newvers.sh; \
>>
>> Now the question is how to fix this?
>>
>> -Kimmo
>
> Perhaps it could be handled similar to PARAMFILE, something like this in
> the makefile:
>
>   PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
>   SYSDIR=${.CURDIR}/../sys; \
>  . ${.CURDIR}/../sys/conf/newvers.sh; \
>
> I'm not sure if newvers.sh needs to work in ways that don't involve
> being invoked from that makefile rule, so to be safe it could have
> default handling, something like:
>
>  : ${SYSDIR:=$(dirname $0)/..}
>
> -- Ian
>
>

Thanks, that works. Should I file a PR about this?

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

/usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory.

2012-12-12 Thread Kimmo Paasiala 
Hello,

My 9-STABLE buildworld broke in a very inexplicable way,  I was
getting an error on /usr/src/include/osreldate.h that I couldn't
figure out until I started looking at the sys/conf/newvers.sh and what
it does. It turned out that the thing that broke my buildworld was
having .git directory at the root directory of the system because I
recently started using GIT to track the configuration files.

I added some debug echos to the newvers.sh and I found out it's
setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set
the gitdir to /.git and that seems to break the logic in newvers.sh.

Isn't SYSDIR supposed to be set to the sys -subdirectory of the source
tree (/usr/src/sys default)?

I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in
newvers.sh:

SYSDIR=$(dirname $0)/..

$0 is actually /bin/sh and not the path to newver.sh because the
newvers.sh is sourced by the Makefile in /usr/src/include instead of
executing it:

osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh ${.CURDIR}/../sys/sys/param.h \
${.CURDIR}/Makefile
@${ECHO} creating osreldate.h from newvers.sh
@MAKE=${MAKE}; \
PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
. ${.CURDIR}/../sys/conf/newvers.sh; \

Now the question is how to fix this?

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

ipv6_addrs_IF aliases in rc.conf(5)

2012-12-07 Thread Kimmo Paasiala 
Hello,

I wrote a small patch for /etc/network.subr to add support for
ipv6_addrs_IF aliases in rc.conf(5) to match the already existing
ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6
aliases can be written like:

ipv6_addrs_re0="2001:db8::::1/64 2001:db8::::2/64"

Only this syntax is supported, it's not possible to use the "prefixlen
nn" syntax in the list.

The patch is against a recent 9-STABLE, last changed rev of
network.subr on my SVN checkout is r242187. I don't have a CURRENT
system to test if it applies to CURRENT as well.

The patch can be found attached to a PR I sent:

http://www.freebsd.org/cgi/query-pr.cgi?pr=174225


I wrote this patch inspired by a question on the FreeBSD forums:

http://forums.freebsd.org/showthread.php?t=36136

Please test and report if it works for you :)


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