Re: [CFC/CFT] large changes in the loader(8) code
Pawel Jakub Dawidek wrote: On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: All of the above is ugly, U'm afraid :( Indeed. The only sane way is to put the metadata in a partition of its own. Every compliant OS will respect that and consequently will not scribble over the data unintentionally. Any other scheme that puts valuable data in some undocumented or unregistered location is violating the GPT spec right away and is susceptible to being clobbered unintentionally. If the user runs: # gpart create -s GPT /dev/mirror/foo for me it is obvious that he wants to partition the mirror device and not individual disks. Because the mirror was configured earlier, do you expect gmirror to somehow detect that someone is writting GPT metadata later and magically place GPT metadata on the raw disk and move mirror's metadata to some magic partition? Not to mention that the mirror itself doesn't have to be configured on top of raw disks. And not to mention that the mirror may never be partitioned. If GPT in your opinion is limited only to raw disks then I guess the best way to fix that is to refuse to configure GPT on anything except raw disks (which was already proposed by Andrey?). In my opinion this is unacceptable, but I think this is what you are suggesting. One of the GEOM design goals was to be flexible. Let the user decide in what order he wants to configure various layers. How do you know that in every possible scenerio software mirroring should come after partitioning and encryption after mirroring? Why can't we provide flexible tools to the user and let him decide? Maybe GPT nesting violates standards, but why can't we support it as an extention, really? I recognize the need to warn users if they use FreeBSD-specific features. We do that with non-standard APIs. So how about this. Let's modify gpart(8) to print a warning if GPT is configured on something else than raw disk. Let's the warning say that such configuration is non-standard and problems are expected if the disk is shared between other OSes. In my opinion that's fair. With such a warning in place, I think we can allow users to decide on their own if they really want that or not. Then, we can also improve FreeBSD boot loader to play nice with FreeBSD-specific extensions. I think this is valid point of view. FreeBSD already does things not supported by other OSes and I am completely fine with it - I am running FreeBSD on servers, not sharing anything with other OSes so I prefer extended FreeBSD specific features over 100% standard compliant behaviour crippling SW mirroring etc. I think that our tools should support / provide all standard compliant (compatible) features, but let user to choose any other extended non-compatible features if user wants it. Even if it can be seen as foot shooting by somebody else. And maybe one day our solution will be widespread and taken as a standard. Miroslav Lachman ___ 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: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Eygene Ryabinkin wrote: Miroslav, good day. Mon, Oct 06, 2008 at 12:41:05AM +0200, Miroslav Lachman wrote: I am busy these days, but it is nice to read about your progress. I hope I will get some time to test all of these large patches in a few days and I will report back my experiences! Fine, thank you! I am re-CC'ing bug-followup@ to track this letter, since it contains some useful information that should go into GNATS. One note before tests... do -n flag always download new INDEX file, or is it possible to use one already existing in /usr/ports? Currently, it is downloads bzipped INDEX file to /var/db/portaudit every time, but it uses mirror mode, so if remote file hadn't changed at all, all network expences are just the HTTP's HEAD request and reply. I can add another variable to the portaudit to force the usage of the existing INDEX file, if it is needed. By the way, how are you keeping your INDEX file up to date (your proposed usage of 'pkg_version -I' implies that you're always rely on it)? I am just curious -- my INDEX files are almost always stay unupdated, even if I am using portupgrade. I have '/usr/sbin/portsnap cron' and '/usr/sbin/portsnap -I update' in my crontab, so I get INDEX updated every night before nightly security e-mail is generated. And there can be another way if one keeps ports tree updated: utility can use 'make' to determine the version that is currently available on the examined host. But downloading the INDEX file from the central server seemed to be the best way, since it almost always gives one the latest port versions, so I had implemented this in a first place. My previous question was not against your solution, it seems useful to have really actual data from the fresh INDEX. It was just a question "how it is done". Maybe someone will be happier to use the existing INDEX because of traffic on some GPRS internet connection or because of the own INDEX creation. (it is not my case, I have all machines as the servers with enough connectivity) ;) Don't know, however, how the badly the load to the central HTTP server will be raised. I am using just two first fields from the INDEX file, so I can use such a stripped file. For me, the reduction was about 6x: SIZE(INDEX-7.bz2) = 1126189, SIZE(INDEX-7.stripped.bz2) = 184345. I am CC'ing the portmgr team. Guys, could you quickly glance over these patches and determine if they are useful to the project in large? If yes, then may be such a stripped INDEX can be created on the FreeBSD servers (via cut -f1-2 -d'|' INDEX-N)? Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Eygene Ryabinkin wrote: Roman, good day. Sat, Sep 27, 2008 at 08:18:08PM +0400, Roman Kurakin wrote: Have you also posted this to [EMAIL PROTECTED] No, forgot to do it. CC'ing ports@ Thanks! The original posting to hackers@ goes below. It will be double-posted to the bug-followup@ -- sorry for this. Eygene Ryabinkin wrote: Good day. A while ago I had created the new utility that serves as VuXML filter for the installed packages: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126853 My primary intention was to speed up the process of auditing the vulnerable ports: I needed to run portaudit checks with Nagios and to avoid large timeouts. The new utility is called pkg_audit and it serves as a simple text filter: on input it takes the full VuXML feed and on output it puts VuXML entries that matches ports that are installed in the system with port version specification substituted with the actual port versions. No harm is done to the actual poartudit -- if pkg_audit is missing, old code path is activated. If someone is interested and will be able to test -- I am all ears. Additional clarifications inspired by the off-line talk with rik@: I could take another route and add this functionality to the pkg_info. I took another approach for the following reasons. 1. pkg_info's option list is already quite big -- around 32 options and switches. 2. It is easier to test for the presence of the new tool (pkg_audit) and use it, instead of checking the support for the new option in pkg_info. 3. I see no options in pkg_info that can be naturally extended to absorbe the new functionality. The closest is '-E', but pkg_audit needs to read VuXML entries, choose ones that are present in the system and output the found VuXML entries with version templates substituted with the real entries, so pkg_audit is filter-like utility. In my opinion, such extension of pkg_info's "-E" will be very unnatural. 4. I feel that it is Unix-way to do the things: create small utilities that do their (small) job in a proper fashion. Moreover, since the majority of a code sits in the pkg_install's library, there is a very slight code duplication, if any. Is there any possibility to cooperate portaudit / pkg_audit with pkg_version to show vulnerable package with information if newer (not vulnerable) package (or port) version is available for upgrade to? If I read nightly security e-mail with for example 4 vulnerable packages, then I need to log in to server and manualy try, if newer (fixed) packages are available. It seems not so hard to check output of `pkg_version -vIL =` and compare both versions (installed and available) with portaudit in some shellscript, I didn't start to write it yet ;). Miroslav Lachman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
