Re: ifconfig accepting hostname as ipv4 address
On Thursday 07 June 2012 17:00:04 Alexander V. Chernikov wrote: > Hello list! > > Since the early days ifconfig(8) has the following functionality: [hostname in place of literal address] > Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you > can't set valid CIDR address using this notation. I'm not sure that's true. Have you tried it? Because it seems to work here. Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ifconfig accepting hostname as ipv4 address
On 08.06.2012 11:20, Jonathan McKeown wrote: On Thursday 07 June 2012 17:00:04 Alexander V. Chernikov wrote: Hello list! Since the early days ifconfig(8) has the following functionality: [hostname in place of literal address] Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you can't set valid CIDR address using this notation. I'm not sure that's true. Have you tried it? Because it seems to work here. Strangely enough, it works on another machine. Ok, this one works and can unfortunately be used by other people. However, original question remains. Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ifconfig accepting hostname as ipv4 address
On Friday 08 June 2012 09:43:25 Alexander V. Chernikov wrote: > On 08.06.2012 11:20, Jonathan McKeown wrote: > > On Thursday 07 June 2012 17:00:04 Alexander V. Chernikov wrote: > >> Hello list! > >> > >> Since the early days ifconfig(8) has the following functionality: > > > > [hostname in place of literal address] > > > >> Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you > >> can't set valid CIDR address using this notation. > > > > I'm not sure that's true. Have you tried it? Because it seems to work > > here. > > Strangely enough, it works on another machine. Ok, this one works and > can unfortunately be used by other people. > > However, original question remains. So your question is, do we want to keep the behaviour of being able to configure an interface by hostname as well as by IP address? My vote is yes. Sure, a typo in the parameters to ifconfig can cause problems under some circumstances. So can a typo in any command. I don't think that's a good enough reason to remove functionality you regard as ``unfortunate''. We find it useful, and a significant aid to maintainability and readability of configuration files. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[Phrack Mag.] The false kingdom of jemalloc, or On exploiting the jemalloc memory manager
An analysis of jemalloc - founded in phrack magazine. --[ Table of contents 1 - Introduction 1.1 - Thousand-faced jemalloc 2 - jemalloc memory allocator overview 2.1 - Basic structures 2.1.1 - Chunks (arena_chunk_t) 2.1.2 - Arenas (arena_t) 2.1.3 - Runs (arena_run_t) 2.1.4 - Regions/Allocations 2.1.5 - Bins (arena_bin_t) 2.1.6 - Huge allocations 2.1.7 - Thread caches (tcache_t) 2.1.8 - Unmask jemalloc 2.2 - Algorithms 3 - Exploitation tactics 3.1 - Adjacent region corruption 3.2 - Heap manipulation 3.3 - Metadata corruption 3.3.1 - Run (arena_run_t) 3.3.2 - Chunk (arena_chunk_t) 3.3.3 - Thread caches (tcache_t) 4 - A real vulnerability 5 - Future work 6 - Conclusion 7 - References 8 - Code [...] "--[ 6 - Conclusion We have done the first step in analyzing jemalloc. We do know, however, that we have not covered every possible potential of corrupting the allocator in a controllable way. We hope to have helped those that were about to study the FreeBSD userspace allocator or the internals of Firefox but wanted to have a first insight before doing so. Any reader that discovers mistakes in our article is advised to contact us as soon as possible and let us know. Many thanks to the Phrack staff for their comments. Also, thanks to George Argyros for reviewing this work and making insightful suggestions. Finally, we would like to express our respect to Jason Evans for such a leet allocator. No, that isn't ironic; jemalloc is, in our opinion, one of the best (if not the best) allocators out there. " http://www.phrack.org/archives/68/p68_0x0a_Pseudomonarchia%20jemallocum_by_argp%20&%20huku.txt http://www.phrack.org/archives/68/p68_0x0d_The%20Art%20of%20Exploitation:%20Exploiting%20VLC,%20a%20jemalloc%20case%20study_by_huku%20&%20argp.txt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: boot menu option to disable graphics mode
On 7 June 2012 16:12, Garrett Cooper wrote: > I've run into _multiple_ scenarios where this isn't possible because > the terminal settings are screwed up in single user mode, and had to > resort to `sed -i '' `. > > ed is the standard text editor Aled ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: CD bootcode
- Original Message - From: John Baldwin To: rank1see...@gmail.com Cc: hack...@freebsd.org Date: Thu, 7 Jun 2012 11:16:33 -0400 Subject: Re: CD bootcode > On Thursday, June 07, 2012 9:58:25 am rank1see...@gmail.com wrote: > > - Original Message - > > From: John Baldwin > > To: freebsd-hackers@freebsd.org > > Cc: rank1see...@gmail.com > > Date: Thu, 7 Jun 2012 08:21:39 -0400 > > Subject: Re: CD bootcode > > But even when loader is finally started, loader handles symlinks on UFS > > (kicked by '/boot/boot'), BUT fails so, on Rock-Ridge iso (kicked by > '/boot/cdboot') > > Looks like loader must be made into looking at Rock-Ridge extensions. > > It is src/lib/libstand/cd9660.c that would have to be patched. It already has > limited Rock-Ridge support, so adding symlink support to cd9660_open() may not > be that hard to do. > > -- > John Baldwin Problem should be solved in 2 groups/steps. First - stage 2 boot '/boot/boot' AND '/boot/cdboot' shouldn't be made into working with symlinks. Just leave them, the way they are. First one can be navigated to loader via 'boot.config' file. So only '/boot/cdboot' should be edited, to react to the same 'boot.config' file as '/boot/boot' does. Simply because they both target 'loader', 'boot.config' should work for both bootcodes. Second -- 'loader' should be edited, to work with Rock-Ridge extensions. Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ifconfig accepting hostname as ipv4 address
On 08.06.2012 11:04, Jonathan McKeown wrote: We find it useful, and a significant aid to maintainability and readability of configuration files. Hello, What happens if your server reboots while the DNS server is down/unavailable ? This seems to be a bad idea for the same reasons that putting hostnames in firewall configs are a bad idea: You want the system to boot and work correctly regardless of whether the systems DNS servers were responsive at boot time or not. Best regards Thomas Steen Rasmussen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: CD bootcode
On Friday, June 08, 2012 10:33:00 am rank1see...@gmail.com wrote: > - Original Message - > From: John Baldwin > To: rank1see...@gmail.com > Cc: hack...@freebsd.org > Date: Thu, 7 Jun 2012 11:16:33 -0400 > Subject: Re: CD bootcode > > > On Thursday, June 07, 2012 9:58:25 am rank1see...@gmail.com wrote: > > > - Original Message - > > > From: John Baldwin > > > To: freebsd-hackers@freebsd.org > > > Cc: rank1see...@gmail.com > > > Date: Thu, 7 Jun 2012 08:21:39 -0400 > > > Subject: Re: CD bootcode > > > > But even when loader is finally started, loader handles symlinks on UFS > > > (kicked by '/boot/boot'), BUT fails so, on Rock-Ridge iso (kicked by > > '/boot/cdboot') > > > Looks like loader must be made into looking at Rock-Ridge extensions. > > > > It is src/lib/libstand/cd9660.c that would have to be patched. It already > > has > > limited Rock-Ridge support, so adding symlink support to cd9660_open() may > > not > > be that hard to do. > > > > -- > > John Baldwin > > > Problem should be solved in 2 groups/steps. > > First > - > stage 2 boot '/boot/boot' AND '/boot/cdboot' shouldn't be made into working > with symlinks. > Just leave them, the way they are. First one can be navigated to loader via > 'boot.config' file. > So only '/boot/cdboot' should be edited, to react to the same 'boot.config' > file as '/boot/boot' does. > Simply because they both target 'loader', 'boot.config' should work for both > bootcodes. Adding /boot.config support to cdboot is non-trivial. Also, cdboot is intended for read-only media, so dynamic configuration via a file is not quite as useful. > Second > -- > 'loader' should be edited, to work with Rock-Ridge extensions. It already supports RR for names, it is merely symlink support that has to be added. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: CD bootcode
> > First > > - > > stage 2 boot '/boot/boot' AND '/boot/cdboot' shouldn't be made into working > > with symlinks. > > Just leave them, the way they are. First one can be navigated to loader via > > 'boot.config' file. > > So only '/boot/cdboot' should be edited, to react to the same 'boot.config' > > file as '/boot/boot' does. > > Simply because they both target 'loader', 'boot.config' should work for > > both bootcodes. > > Adding /boot.config support to cdboot is non-trivial. Also, cdboot is > intended for read-only media, so dynamic configuration via a file is not > quite as useful. cdboot is a FreeBSD specific Fact that it is intended for RO media is irrelevant here, as stage 2 boot can also reside on RO fs. For cdboot, 'boot.config' file should give instructions of full path to loader, nothing else (no other, stage 2 boot's flags/functionality). Hm, then again, if cdboot file would inherit just that 1 functionality, then it can't share same config file. How about 'cdboot.config' file name? Thanks to boot.config, I specify full path to loader, so '/boot/boot' isn't "halted" by symlink. If cdboot would obey it in a same way, I wouldn't have to patch it, by adding third path. Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: nss compat shims
I don't know for sure, but it seems that there was no need to support anything besides groups and password when nss_compat.c was committed. At that time, IIRC, the modules that we had in ports supported only these databases. -- Michael On Thu, Jun 7, 2012 at 2:43 PM, Mel Flynn wrote: > Hi, > > I'm currently implementing support for more NSS databases in > net/nss-pamd-ldapd and I've started to wonder why there's only the group > and password support in lib/libc/net/nss_compat.c? > > Is there a specific reason for it or is this a classic case of "patches > welcome"? I wasn't able to determine the reason from the commit log. > -- > Mel > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ifconfig accepting hostname as ipv4 address
On Fri, Jun 8, 2012 at 10:08 AM, Thomas Rasmussen wrote: > On 08.06.2012 11:04, Jonathan McKeown wrote: >> >> We find it useful, and a significant aid to maintainability and >> readability >> of configuration files. > > Hello, > > What happens if your server reboots while the DNS > server is down/unavailable ? Shouldn't this still work if the machine has its own hostname associated with its IP in /etc/hosts? Is that not still common practice? I can see the logic here. By putting the IP in /etc/hosts and the hostname in the ifconfig, you only have to edit the address in one place if it ever changes. This reminds me that the old (pre-NWAM) way to configure Solaris with a static IP was to put the IP and hostname in /etc/hosts, the hostname in /etc/hostname.e1000g0 (or whatever your interface name was), the gateway address in /etc/defaultrouter, and the network address and netmask in /etc/netmasks. -- David Brodbeck System Administrator, Linguistics University of Washington ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: boot menu option to disable graphics mode
On Thu, Jun 07, 2012 at 01:06:09PM +0300, Andriy Gapon wrote: > on 07/06/2012 12:57 Gleb Kurtsou said the following: > > What do you think about adding generic support for overriding *_enable > > options in rc.conf? > > > > I'd like to be able to disable services at boot prompt, e.g. > > # set rc.slim_enable="no" -- overrides slim_enable="yes" in rc.conf > > > > Similarly rc.pf_enable="no" > > > > Then introduce x_enable knob (=yes by default) to disable login > > managers. User will be able to override this setting with > > # service xdm forcestart > > I think that this is an excellent idea. > runlevel support might be a better solution so it does not differ that much from what other systems do and would be easy for people to grasp. -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: boot menu option to disable graphics mode
on 09/06/2012 04:16 Jason Hellenthal said the following: > runlevel support might be a better solution so it does not differ that > much from what other systems do and would be easy for people to grasp. Patches are welcome, as always. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"