Re: timezone for 100.chksetuid
On Fri, May 16, 2014 at 2:53 PM, J.R. Oldroyd f...@opal.com wrote: I would like to propose that a timezone setting be possible for the src/etc/periodic/security/100.chksetuid script. Either fix it at something like UTC, or add an rc.conf setting that specifies what timezone to use. Or both, default to UTC but allow a timezone setting in rc.conf. Reason for this is that for folk who travel, the 100.chksetuid script generates and diffs find -ls output and this output changes if you change timezones and update the system timezone setting while you are away. It then changes back again when you return. If you travel a lot, the two timezone changes cause this script to flag every setuid file as having changed (twice), when all that changed is the time display. This means that real changes during the same period will likely be overlooked and the frequent non-real diffs tend to make one likely to ignore this section. Do you mean you are changing /etc/localtime whenever you move to another timezone? I would suggest stopping doing that! Instead just set TZ in your user environment to whatever TZ you want. That way, your programs will all be localised correctly, and scripts which run as root will remain consistent. Cheers Tom ___ 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: ZFS bug or feature
On Tue, Apr 22, 2014 at 5:18 PM, Andrey Fesenko f0and...@gmail.com wrote: After detach ada0 and attach him (reboot between that) boot only one disk Apr 17 13:33:52 x220 kernel: ada0 at ahcich2 bus 0 scbus0 target 0 lun 0 Apr 17 13:33:52 x220 kernel: ada0: OCZ-NOCTI 2.15 ATA-8 SATA 2.x device Apr 17 13:33:52 x220 kernel: ada0: Serial Number OCZ-J8928HU1G10KR9XM Apr 17 13:33:52 x220 kernel: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Apr 17 13:33:52 x220 kernel: ada0: Command Queueing enabled Apr 17 13:33:52 x220 kernel: ada0: 114473MB (234441648 512 byte sectors: 1H 63S/T 65535C) Apr 17 13:33:52 x220 kernel: ada0: Previously was known as ad4 After attach ada0 im see this # camcontrol devlist Corsair Neutron SSD M206 at scbus0 target 0 lun 0 (ada0,pass0) OCZ-NOCTI 2.15 at scbus1 target 0 lun 0 (ada1,pass1) # zpool status pool: x220pool state: ONLINE status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(7) for details. scan: resilvered 42.4M in 0h0m with 0 errors on Thu Apr 17 13:48:42 2014 config: NAME STATE READ WRITE CKSUM x220pool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 diskid/DISK-OCZ-J8928HU1G10KR9XMs1a ONLINE 0 0 0 ada0s1a ONLINE 0 0 0 errors: No known data errors # gpart show = 63 468862065 ada0 MBR (224G) 63 234441585 1 freebsd (112G) 234441648 234420480 2 freebsd (112G) =0 234441585 ada0s1 BSD (112G) 0 234441585 1 freebsd-zfs (112G) = 63 234441585 diskid/DISK-OCZ-J8928HU1G10KR9XM MBR (112G) 63 234441585 1 freebsd [active] (112G) =0 234441585 diskid/DISK-OCZ-J8928HU1G10KR9XMs1 BSD (112G) 0 234441585 1 freebsd-zfs (112G) Apr 17 13:48:43 x220 kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 Apr 17 13:48:43 x220 kernel: ada0: Corsair Neutron SSD M206 ATA-8 SATA 3.x device Apr 17 13:48:43 x220 kernel: ada0: Serial Number 124079271802000A Apr 17 13:48:43 x220 kernel: ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) Apr 17 13:48:43 x220 kernel: ada0: Command Queueing enabled Apr 17 13:48:43 x220 kernel: ada0: 228936MB (468862128 512 byte sectors: 16H 63S/T 16383C) Apr 17 13:48:43 x220 kernel: ada0: Previously was known as ad4 Apr 17 13:48:43 x220 kernel: ada1 at ahcich2 bus 0 scbus1 target 0 lun 0 Apr 17 13:48:43 x220 kernel: ada1: OCZ-NOCTI 2.15 ATA-8 SATA 2.x device Apr 17 13:48:43 x220 kernel: ada1: Serial Number OCZ-J8928HU1G10KR9XM Apr 17 13:48:43 x220 kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Apr 17 13:48:43 x220 kernel: ada1: Command Queueing enabled Apr 17 13:48:43 x220 kernel: ada1: 114473MB (234441648 512 byte sectors: 1H 63S/T 65535C) Apr 17 13:48:43 x220 kernel: ada1: Previously was known as ad6 # zpool history -il | tail -6 2014-04-17.13:33:51 [txg:8004153] open pool version 5000; software version 5000/5; uts 11.0-CURRENT 115 amd64 [on x220.local] 2014-04-17.13:48:36 [txg:8004321] open pool version 5000; software version 5000/5; uts 11.0-CURRENT 115 amd64 [on x220.local] 2014-04-17.13:48:41 [txg:8004324] scan setup func=2 mintxg=8004151 maxtxg=8004320 [on x220.local] 2014-04-17.13:48:42 [txg:8004325] scan done complete=1 [on x220.local] 2014-04-17.13:53:53 zpool clear x220pool [user 0 (root) on x220.local] I'm confused, what is the bug or feature? Has it added the disk with the wrong label? You can correct that with an zpool export x220pool / zpool import -d /dev/diskid x220pool Cheers Tom ___ 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: Error when adding user with multiple groups with bsdconfig
On Fri, Jan 10, 2014 at 12:37 AM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: Hi I'm on 11-CURRENT amd64. I wanted to add a user using bsdconfig but got an error when adding to several groups. Error message: ERROR!: pw pw: group `wheel daemon operator dialer network` does not exist. Creating a user who is only added to one group (for example wheel) works fine. I have submitted a PR. What command line did you use? A user can only have one primary group (-g), but can be in multiple groups (-G). -g group Set the account's primary group to the given group. group may be defined by either its name or group number. -G grouplist Set additional group memberships for an account. grouplist is a comma, space or tab-separated list of group names or group numbers. The user's name is added to the group lists in /etc/group, and removed from any groups not specified in grouplist. Note: a user should not be added to their pri‐ mary group with grouplist. Also, group membership changes do not take effect for current user login sessions, requir‐ ing the user to reconnect to be affected by the changes. Cheers Tom ___ 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: Feature Proposal: Transparent upgrade of crypt() algorithms
On Fri, Mar 7, 2014 at 2:13 PM, John Baldwin j...@freebsd.org wrote: On Wednesday, March 05, 2014 3:09:30 pm Matthew Rezny wrote: Password expiry is an orthogonal issue and should be up to administrator policy. Yes, but if you are moving to a different algorithm to improve security, not coupling it with an eventual expiration of non-migrated accounts gives a false sense of security. Any admin worth his/her salt is going to want the option of enforcing that sort of policy along with the transparent update. They should really be implemented together is all. Account expiration and password expiration are already present. There is absolutely no reason that password algorithm upgrade should be tied in any way to expiration. A transparent algorithm upgrade as proposed is *far* better than the forced password change method that is commonly employed. If the administrator wants to force all accounts to migrate by a set deadline, we already have the expiration facilities in place to accomplish that. Expiring accounts that have not been used in a long time, regardless of algorithm changes, should be part of general housekeeping and may be covered by existing policy. Password expiration serves no purpose, EVER. Password expiration encourages users to choose bad passwords because they are throwaway items. Bruce states it well enough I need not elaborate further https://www.schneier.com/blog/archives/2010/11/changing_passwo.html Anyone who fails to understand the above should NOT be an administrator. I think you failed to understand my point. I am assuming that an administrator wants the transparent upgrade (which I think is useful) because they are assuming that the hash algorithm is compromised or inferior. To that end, they may wish to limit the time window for which they accept hashes generated using the suspect algorithm. This is separate (I believe) from the issue Bruce raises above. For example, in this case, the administrator is perfectly happy for the actual plaintext to remain the same, the administrator simply wants to enforce the new hash. As far as I can tell, there is nothing in /etc/login.conf to allow for automatic account expiration if an account is idle for more than N days. OTOH, even that is probably not sufficient for the original case since a user might login with a different authentication method (e.g. ssh key) that would reset the idle timer without updating the hash. I suppose if you really were paranoid about the hash what you would want is an ability to set an expiration time on the hash algo itself where authentication using that hash always fails after the expiration time. This doesn't necessarily expire the entire account (e.g. ssh key auth would still work), though it might be a bit surprising to the user to find that the next time they attempt to use password authentication it doesn't work. (You would at least want a warning about the hash being expired on login via another mechanism.) All of this is orthogonal to adding a way to upgrade hashes. Yes, all of the points you mentioned are relevant to general password security, but doesn't explain why a feature that provides transparent hash upgrades cannot be added without first adding the features you are asking for. It's like trying to prevent people from shooting themselves in the foot by only giving them rocks to throw. Cheers Tom ___ 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: fonts and characters
On Fri, Feb 7, 2014 at 3:57 PM, Sean Bruno sean_br...@yahoo.com wrote: 1 question though, I see that LANG isn't set by default. Should I know where to modify my system to set en_US.UTF-8 or is it supposed to have that turned on by default? /etc/profile is where I set it on mine. Cheers Tom ___ 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: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
On Thu, Feb 6, 2014 at 6:34 PM, Julian H. Stacey j...@berklix.com wrote: Best avoid the obscure word `Deprecated' in manuals: It's not common/ plain English. Maybe a geek import, or USA dialect ? It's not easily internationaly understood English. Best make manuals easier for non native English speakers ( native English too ;-). I am British born bred, whether in English speaking circles in UK or Germany I never hear or read 'deprecated' unless its in BSD context. Few native English speakers I know will be immediately sure of the meaning, it's too obscure. As another Briton this surprises me: The word deprecate has a clear and specific meaning in all computing, especially in standards, release notes and documentation. It is from latin and is the same base word in all romance languages. It is definitely in common usage in the UK, I would not hesitate to use it any conversation with anyone and expect them to understand its meaning. To my ear there is no clearer word to use for this purpose. Cheers Tom ___ 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: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
On Thu, Dec 19, 2013 at 12:33 PM, Thomas Mueller mueller6...@bellsouth.net wrote: Better would be if manufacturers' and online vendors' websites would say what chipset their Ethernet, Bluetooth adapter, USB wi-fi adapter, etc use. I think manufacturers don't consider this relevant info, they sell features, not the underlying spec. This allows them to chop and change what chip is actually in a device depending on the vagaries of their supply chain. Eg, Rev A, Rev B might be precisely the same packaging but different chips underneath. Suck for non Windows users, I agree. Cheers Tom ___ 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: [request] ntp upgrade
On Wed, Nov 27, 2013 at 3:29 PM, Cristiano Deana cristiano.de...@gmail.com wrote: Hi, is it possible to include in base system of the upcoming 10.0 the new version of ntp (4.2.7 instead of 4.2.4)? There is a bug in older versions ( 4.2.7) who allows attacker use an ntp server to DDoS. This has been corrected in new version: https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks This attack seems to be increasing in the last few weeks. net/ntp-devel is Ok. Thank you, sorry for my basic english. ntp 4.2.4p8 isn't vulnerable. http://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html The reflection attack is the first in the list, 4.2.4p7 and below are affected. Cheers Tom ___ 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: [request] ntp upgrade
On Wed, Nov 27, 2013 at 4:10 PM, Cristiano Deana cristiano.de...@gmail.com wrote: On Wed, Nov 27, 2013 at 5:06 PM, Tom Evans tevans...@googlemail.com wrote: There is a bug in older versions ( 4.2.7) who allows attacker use an ntp server to DDoS. This has been corrected in new version: https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks This attack seems to be increasing in the last few weeks. net/ntp-devel is Ok. ntp 4.2.4p8 isn't vulnerable. http://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html The reflection attack is the first in the list, 4.2.4p7 and below are affected. Thank you, Tom for your quick reply. That is not the same bug. I had two ntpd with 4.2.4p8 used the last days to DDoS. I found the link below, used net/ntp-devel and the abuse was gone. Does it have a CVE? The article is low on content :( Cheers Tom ___ 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: mplayer
On Thu, Sep 19, 2013 at 10:06 PM, Ajtim lum...@gmail.com wrote: I try to built Mplayer but I have a problems (they were so many warnings) and finally error: libmpdemux/demux_rtp.cpp:101:20: error: no member named 'describeWithPassword' in 'RTSPClient' return client-describeWithPassword(url, network_username, password); ~~ ^ libmpdemux/demux_rtp.cpp:103:20: error: no member named 'describeURL' in 'RTSPClient' return client-describeURL(url); Live555 (net/liveMedia) changed their API, you either have too new a version of that library with too old an mplayer snapshot, or too old version of that library with too new of an mplayer snapshot. Either way, update all ports that mplayer depends on and try again. If it still doesn't work, update your ports tree, update all ports that mplayer depends on and try again. You could also disable Live555 support if you don't need RTSP. Cheers Tom ___ 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 is very slow when Memory chip sizes are imbalanced in slots
On Sun, Mar 17, 2013 at 8:26 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: Dear All , Previously , in the following message , I have mentioned effect of memory chip placement on execution speed : http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html Effect of Processor and Memory on KDE4 execution speedhttp://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html These seems to be more than different memory slot allocation between those two boxes. Can you reproduce this on the one labelled 'FAST' by assigning memory in the same manner as it is assigned in the one labelled 'SLOW'? The above thread did not produce any usable result . The problem is persisting over 9.1 and 10.0 current . My opinion is that , it is NOT related to KDE only . After X is started , any desktop is behaving very slowly . This is also visible in PC-BSD and GhostBSD . This is very nebulous. What is 'very slowly'? Is there a test you can run that is independent of X, KDE, etc that demonstrates this? One thing that KDE does require (iirc - from about 5 years ago, probably wrong now) is that since KDE is C++, it spends a lot of time loading executables/libraries into memory and prelinking them. If you have dramatically lowered your RAM bandwidth, then this stage could take a lot longer. One thing that could cause memory bandwidth to lower is by installing mismatched modules. The BIOS will set all RAM up at the same speed, the lowest that all of the installed RAM supports. If you fill the RAM slots with mismatched modules of different sizes, it may also not enable dual channel memory, further reducing the RAM bandwidth. Because of this, I think it is a jump to go from My computer runs slow when I put these bits of RAM in to FreeBSD always runs slow when there is mismatched RAM. If you find out what is slow on FreeBSD - eg RAM bandwidth - you can then test the same thing in Linux. If Linux shows the same slowdown from fast to slow, then I'm sorry, that's a hardware defect. If, on the other hand, Linux is just as fast in both configurations, then I'm sure a lot of people would be interested as to why. Cheers Tom ___ 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 is very slow when Memory chip sizes are imbalanced in slots
On Mon, Mar 18, 2013 at 10:30 AM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Mon, Mar 18, 2013 at 3:01 AM, Tom Evans tevans...@googlemail.com wrote: On Sun, Mar 17, 2013 at 8:26 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: Dear All , Previously , in the following message , I have mentioned effect of memory chip placement on execution speed : http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html Effect of Processor and Memory on KDE4 execution speedhttp://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html These seems to be more than different memory slot allocation between those two boxes. Can you reproduce this on the one labelled 'FAST' by assigning memory in the same manner as it is assigned in the one labelled 'SLOW'? The above thread did not produce any usable result . The problem is persisting over 9.1 and 10.0 current . My opinion is that , it is NOT related to KDE only . After X is started , any desktop is behaving very slowly . This is also visible in PC-BSD and GhostBSD . This is very nebulous. What is 'very slowly'? Is there a test you can run that is independent of X, KDE, etc that demonstrates this? One thing that KDE does require (iirc - from about 5 years ago, probably wrong now) is that since KDE is C++, it spends a lot of time loading executables/libraries into memory and prelinking them. If you have dramatically lowered your RAM bandwidth, then this stage could take a lot longer. One thing that could cause memory bandwidth to lower is by installing mismatched modules. The BIOS will set all RAM up at the same speed, the lowest that all of the installed RAM supports. If you fill the RAM slots with mismatched modules of different sizes, it may also not enable dual channel memory, further reducing the RAM bandwidth. Because of this, I think it is a jump to go from My computer runs slow when I put these bits of RAM in to FreeBSD always runs slow when there is mismatched RAM. If you find out what is slow on FreeBSD - eg RAM bandwidth - you can then test the same thing in Linux. If Linux shows the same slowdown from fast to slow, then I'm sorry, that's a hardware defect. If, on the other hand, Linux is just as fast in both configurations, then I'm sure a lot of people would be interested as to why. Cheers Tom I think , all of the answers to your questions may be found in the above referenced thread messages : Nope, you tested 'running KDE' and on different computers found out that one runs at a different speed than another. You've not done anything else to determine why or because of what. You're the one seeing this problem. If you want it fixed, you will need to do some work to determine what is causing it. All you are saying now is When I build this complex combination of hardware and software, it's slow. Fix my special case. Every possible combination has been tried , and identified that the problem is different memory chip sizes for FreeBSD ( v9.0 , v9.1 , v10.0 ) ( GhostBSD , PC-BSD , v9.0 , v9.1 ) : Channel A : Slot 1 : 2 GB Slot 2 : 1 GB Channel B : Slot 1 : 2 GB Slot 2 : 1 GB All of the memory chips : Kingston HyperX , same clock frequency . Memory placement kind is correct . You say this, have you actually measured/checked. sysutils/dmidecode will interrogate your BIOS and tell us what it thinks is installed in each RAM socket. It is not uncommon for RAM to say one thing on the outside, and report something completely different to the BIOS. There is NO any hardware defect . Linux is insensitive to such different memory chip sizes ( I am using Fedora , CentOS , Mandriva , Mageia , OpenSUSE , Arch Linux , Puppy Linux , and some others ... ) And you've run the tests which clearly demonstrate this? Or you've installed KDE, and it's not been 'too slow'? I'm trying to get you to approach a more scientific approach to this. Hopefully, this would lead to some actual conclusions and things that can be improved, rather than FreeBSD is slow. You've got a problem when you have mismatched memory, your computer runs slower. Is the memory running slower? Test memory bandwidth in both 'fast' and 'slow' configurations. Is there a difference? Apparently linux is unaffected. Test memory bandwidth in both fast and slow configurations on linux. Is there a difference? Doing those 4 steps should tell us more about your actual problem, and might spur an idea in someone. You can use ramspeed to test ram speed in both linux and freebsd: http://alasir.com/software/ramspeed/ Problems with your memory modules should produce testable scenarios that don't involve X and KDE. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr
Re: using multiple interfaces for same Network Card
On Tue, Mar 12, 2013 at 7:43 AM, Yasir hussan kolya...@gmail.com wrote: Hi guys, Is there any way that i can have multiple interfaces which i can able to access from any other machine for same single network card, I am able to create new interfaces like # ifconfig arge0.1 create but i am unable to access it frm any other machine. I want it be able to oing from any other machine Thanks I see you asked about this yesterday: https://groups.google.com/forum/?fromgroups=#!topic/mailing.freebsd.current/uP9BC7_dSrA ifconfig iface create is how aliases are created on linux. You need to use ifconfig iface addr alias on FreeBSD. As was pointed out to you yesterday when you asked. Cheers Tom ___ 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: Re: ports include /etc/src.conf? i.e. graphics/libfpx
On Thu, Feb 14, 2013 at 12:27 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: 13.02.2013 11:22, O. Hartmann написав(ла): 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 For one, the particular port (its Makefile.bsd) was created in 2001, five years before src.conf appeared. The intent of creating a separate src.conf, I believe, was to shield a world-build from crazy options someone could've put into their make.conf for the benefit of building a port or two... But I may be mistaken. I think src.conf is meant only to be included when building src. For example, bsd.port.mk sets _WITHOUT_SRCCONF before including bsd.own.mk (which is the makefile that includes src.conf). It's done this since src.conf was added in 2006, so evidently ports are, by design, not supposed to include src.conf. I would consider them broken! On the contrary. I wish, more ports were using the system's bsd.*.mk collection -- instead of the godawful autoconf, for example. Er? What port uses autoconf for driving the building the port? A lot of ports have build systems that use autoconf, but determining how to build is always driven by *.mk. I don't think part of porting to FreeBSD should be rewriting how the package builds itself. The intent in bsd.port.mk is clearly to not include src.conf in port builds. What does the port's Makefile.bsd say? It says: These are the sources, this is the name of the library I want. Please, create it. That's all... It is how things are supposed to be, in my opinion. If the bsd.*.mk collection was not meant to be used outside of /usr/src, then it wouldn't be installed (under /usr/share/mk) for the decades, that BSD exists. Maybe, the bsd.*.mk collection should be smarter -- and not include src.conf -- when .CURDIR is outside of /usr/src. I'm not sure... This is the intent of bsd.port.mk, which is not applied when building this port. How could I track down problems if they are results of intermixed config files when the manpage explicitely tells me, that the /etc/src.conf is only for the build of the operating system? If the manual says that, it is incorrect -- if only because it does not reflect (as you've experienced) the practice, that existed long before the manual was written. As for your tracking down problems, I'd say, it should be very easy for you to recognize the flags you've added by hand -- even if you've added them to where you believed, they would not affect a port. Either the documentation is wrong, and should be changed, or this singular port is not behaving as it should. Cheers Tom ___ 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
On Thu, Feb 14, 2013 at 1:12 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: I may sound defensive here, but I'll still repeat, that this singular port (and I do, in fact, have other ones like it) started using bsd.lib.mk 5 years before src.conf (and its man-page) was added to the tree. -mi This is true. But what is the bug, that the port's Makefile.bsd was not updated on the introduction of src.conf to DTRT (and no-one noticed for 7 years), or that the purpose of src.conf has been mistakenly documented for 7 years? Cheers Tom ___ 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
On Wed, Feb 13, 2013 at 12:30 PM, Yamaya Takashi yama...@kbh.biglobe.ne.jp 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 bsd.lib.mk, /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 ___ 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: Expanding ZFS RAIDZ on the fly?
On Fri, Jan 11, 2013 at 7:10 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: My question may sound naiv, sorry. I have already set up a RAIDZ (on FreeBSD 10.0-CUR), comprised with three 3 TB disks. I'd like to expand the array with an additional disk - on the fly. oh It's not possible to expand by just 1 disk. Expanding with another 3 disks is possible though, or backup, destroy, create, restore. Expanding or reducing the number of disks in a raidz is the mythical block pointer rewrite functionality, google will tell more. Cheers Tom ___ 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: Removing firewire support from GENERIC
On Fri, Oct 19, 2012 at 3:25 PM, Dag-Erling Smørgrav d...@des.no wrote: Firewire is - a significant security risk - an obstacle to functining suspend / resume on many systems - rapidly becoming obsolete - available as a module The attached patch removes it from GENERIC across the board. Any serious objections before I commit it to head? DES Hi DES Would dcons over firewire still work in GENERIC, with firewire as a module? Cheers Tom ___ 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: Buying recommendation for silent router/fileserver
On Fri, Oct 12, 2012 at 10:58 AM, Ulrich Spörlein u...@freebsd.org wrote: Btw, eSATA is supposed to simply show up as another SATA port in FreeBSD, right? No special driver supported needed for that one? Yep, I have an eSATA hard drive dock, drop the drive in and it is instantly recognised. The eSATA port in my case comes from Intel ICH10, and uses ahci(4). Cheers Tom ___ 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: Buying recommendation for silent router/fileserver
On Thu, Oct 11, 2012 at 3:54 PM, Ulrich Spörlein u...@freebsd.org wrote: Hey guys, I need to replace an aging Pentium IV system that has been serving as my router, access point, file- and mediaserver for quite some time now. The replacement should have: - amd64 CPU (for ZFS, obviously) - 2x GigE (igress, egress interfaces) - some form of wlan interface (I currently use an Atheros based PCI card) … For Wifi I can always fall back to sticking in a supported USB stick, although that's kinda hacky. Are you planning to have the wifi act as an access point? Very few USB wlan devices support hostap mode; and those that do, don't support it very well. I've used a ural(4) stick in hostap before; any client that supports client power save, and that you can't disable power save on, will fall lose link as soon as it tries to enable power save. I don't know of any other wifi sticks that support hostap. Cheers Tom ___ 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: nice-ing a service?
On Wed, Sep 12, 2012 at 11:31 AM, Ivan Voras ivo...@freebsd.org wrote:
Hi,
For whatever reason, I'd like to start services, from a properly formed
rc.d script, configured via /etc/rc.conf, etc. with a custom nice
value. Is there already support for this?
rc.subr indicates you can use ${name}_nice for this purpose.
Cheers
Tom
___
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: Migrating from FreeBSD 9.0-STABLE/amd to 10.0-CURRENT/amd64?
On Tue, Mar 6, 2012 at 4:09 PM, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: Hello. […] Well, I tried to switch by doing a svn switch in /usr/src, building a kernel, restarting the kernel in single user mode and then trying to build the world. At some point in /usr/src/share (I forgot were exactly, it was somewhere with lots of locale stuff), the buildworld process fails so I couldn't build a world. /usr/src/UPDATING says this: To upgrade in-place from 8.x-stable to current -- make sure you have good level 0 dumps make buildworld [9] make kernel KERNCONF=YOUR_KERNEL_HERE [8] [1] reboot in single user [3] mergemaster -p [5] make installworld mergemaster -i [4] make delete-old [6] reboot Even though it says 8.x, I would start from these instructions. Cheers Tom ___ 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: Problem with ACPI / reboot: Black Screen? Part No 2
On Tue, Jan 10, 2012 at 7:12 PM, Fischer Markus mfisc...@reitzner.de wrote: Hello, I habe a BIG Problem with the ACPI Interface. The problem is the reboot command. The Shutdown command works. I don't think ``reboot`` is the command you want. If you want the computer to shut down, and then restart, you should use ``shutdown -r now``, which will invoke ``reboot`` at the appropriate point. Easy enough to check... Cheers Tom ___ 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: bsdinstall kbdmap
On Thu, Jan 5, 2012 at 12:58 AM, Edwin L. Culp W. edwinlc...@gmail.com wrote: I really appreciate your help but I am having a hard time understanding because this has been working perfectly on FreeBSD 9.0 since new. ( 4 months ago ) Just incase it is important. # uname -a FreeBSD home.encontacto.net 9.0-STABLE FreeBSD 9.0-STABLE #44: Wed Jan 4 05:03:08 CST 2012 r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO amd64 My rc.conf has keymap=spanish.iso.acc.kbd Are you sure this is right? My rc.conf has: keymap=uk.iso ie, no '.kbd' file ending, which is implied. I have no /etc/X11 configuration file and haven't ever needed one. The mouse has never had a problem until I reset the server this morning. Mouse? I thought you were talking about keyboard! To get the correct keymap in X from hal, you need to add a policy file, exactly as described in the handbook. Possibly you didn't have hal enabled in earlier X builds, but if you want it to work with hal, you need the policy file. Cheers Tom ___ 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: Dog Food tm
On Thu, Dec 8, 2011 at 3:55 PM, Sean Bruno sean...@yahoo-inc.com wrote: On Thu, 2011-12-08 at 02:08 -0800, Peter Maloney wrote: And what problems did you run into? More or less, trying to do gmirror(4) style mirroring on GPT partitions doesn't work. See http://www.freebsd.org/doc/handbook/geom-mirror.html for the BIG RED WARNING that says why. Er, gmirroring GPT _partitions_ works just fine. It is when you try to gmirror an entire disk that is partitioned with GPT that you have issues, as gmirror trashes the secondary GPT table at the end of the disk. You do not have that issue with individual GPT partitions. Cheers Tom ___ 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: CVS removal from the base
On Sat, Dec 3, 2011 at 3:24 PM, Max Khon f...@samodelkin.net wrote: CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. I wasn't going to jump onto this bikeshed, as CVS will not be going anywhere any time soon, I am sure. I use cvs, rather than csup. I use cvsup to fetch CVS archives to /home/ncvs, and check out ports from there, as described in development(7). If ports were no longer delivered via CVS, you may have had a point about removing CVS from base - but they are not. In my mind, a first step would be to move ports to subversion, initially using svn-cvs bridge. Once done, the next step would be to change all infrastructure scripts so that they can build from/be driven by subversion. After that, nothing in base would use cvs for any purpose, and at that point I would be happy for it to be dropped from base - but only if it was replaced by subversion. I think it is important that with a base install of FreeBSD you can check out and update the source and rebuild itself. Cheers Tom ___ 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: CVS removal from the base
On Mon, Dec 5, 2011 at 3:12 PM, Lowell Gilbert freebsd-current-lo...@be-well.ilk.org wrote: Tom Evans tevans...@googlemail.com writes: On Sat, Dec 3, 2011 at 3:24 PM, Max Khon f...@samodelkin.net wrote: CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. I wasn't going to jump onto this bikeshed, as CVS will not be going anywhere any time soon, I am sure. I use cvs, rather than csup. I use cvsup to fetch CVS archives to /home/ncvs, and check out ports from there, as described in development(7). If ports were no longer delivered via CVS, you may have had a point about removing CVS from base - but they are not. Max Khon was the one who posted the original message in the thread. That message explicitly stated that moving ports and doc away from CVS was a prerequisite for removing CVS from base. As far as I've noticed, no one has challenged that. I'm trying to think of a way to fit the previous paragraph into the bikeshed metaphor, but I'm coming up with nothing. The bikeshed is discussing about how cvs will eventually be removed from base when there are known, unsolved, issues that block that happening. Removing CVS will be an emotive issue, there is no need to discuss it until appropriate, as every one (like me) will wade in saying that x is good and must stay and x is bad and must die, and every colour of bike shed in between. Just look at the number of replies to this topic. It would be much better to concentrate on the other issues rather than animated discussion of something that cannot realistically happen for quite some time yet. Cheers Tom ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Fri, Oct 28, 2011 at 11:05 AM, Thomas Mueller mueller6...@bellsouth.net wrote: Update: the fix didn't work, even though I have the necessary things in master.passwd and /etc/rc.conf . Did you re-run pwd_mkdb? How does one run mergemaster without running roughshod over existing configuration? So when mergemaster runs, it will ask you if you want to (i)nstall (d)elete or (m)erge the changes. If there are no additions to the file - eg new users or groups from the source - then you can just delete the update. If there are new users/groups, you need to merge them in. If you choose merge for /etc/group and /etc/master.passwd, it will show you the differences, and ask you to choose from the option on the left (your original file) or the right (the updated file) to merge them in. Cheers Tom PS Here is a log of me updating my /etc/group, as a new group 'hast' has been added that is not in my /etc/group *** Displaying differences between ./etc/group and installed version: --- /etc/group 2011-05-05 10:54:43.0 +0100 +++ ./etc/group 2011-10-28 11:39:54.0 +0100 @@ -1,11 +1,11 @@ -# $FreeBSD: src/etc/group,v 1.35.10.1.6.1 2010/12/21 17:09:25 kensmith Exp $ +# $FreeBSD: stable/8/etc/group 220104 2011-03-28 17:41:10Z trociny $ # -wheel:*:0:root,tom +wheel:*:0:root daemon:*:1: kmem:*:2: sys:*:3: tty:*:4: -operator:*:5:root,tom +operator:*:5:root mail:*:6: bin:*:7: news:*:8: @@ -26,21 +26,7 @@ dialer:*:68: network:*:69: audit:*:77: -www:*:80:tom +www:*:80: +hast:*:845: nogroup:*:65533: nobody:*:65534: -tom:*:1001: -cyrus:*:60: -messagebus:*:556: -avahi:*:558: -polkit:*:562: -haldaemon:*:560: -pulse:*:563: -pulse-access:*:564: -pulse-rt:*:557: -gdm:*:92: -pgsql:*:70: -rabbitmq:*:135: -_sabnzbd:*:350: -squid:*:100: -webcamd:*:145:tom Use 'd' to delete the temporary ./etc/group Use 'i' to install the temporary ./etc/group Use 'm' to merge the temporary and installed versions Use 'v' to view the diff results again Default is to leave the temporary file to deal with by hand How should I deal with this? [Leave it for later] m # $FreeBSD: src/etc/group,v 1.35.10.1.6.1 2010/12/21 17:09:25 kensmith Exp $ |# $FreeBSD: stable/8/etc/group 220104 2011-03-28 17:41:10Z trociny $ %r wheel:*:0:root,tom| wheel:*:0:root %l operator:*:5:root,tom | operator:*:5:root %l www:*:80:tom | www:*:80: hast:*:845: %r tom:*:1001: cyrus:*:60: messagebus:*:556: avahi:*:558: polkit:*:562: haldaemon:*:560: pulse:*:563: pulse-access:*:564: pulse-rt:*:557: gdm:*:92: pgsql:*:70: rabbitmq:*:135: _sabnzbd:*:350: squid:*:100: webcamd:*:145:tom %l Use 'i' to install merged file Use 'r' to re-do the merge Use 'v' to view the merged file Default is to leave the temporary file to deal with by hand *** How should I deal with the merged file? [Leave it for later] v # $FreeBSD: stable/8/etc/group 220104 2011-03-28 17:41:10Z trociny $ # wheel:*:0:root,tom daemon:*:1: kmem:*:2: sys:*:3: tty:*:4: operator:*:5:root,tom mail:*:6: bin:*:7: news:*:8: man:*:9: games:*:13: ftp:*:14: staff:*:20: sshd:*:22: smmsp:*:25: mailnull:*:26: guest:*:31: bind:*:53: proxy:*:62: authpf:*:63: _pflogd:*:64: _dhcp:*:65: uucp:*:66: dialer:*:68: network:*:69: audit:*:77: www:*:80: hast:*:845: nogroup:*:65533: nobody:*:65534: tom:*:1001: cyrus:*:60: messagebus:*:556: avahi:*:558: polkit:*:562: haldaemon:*:560: pulse:*:563: pulse-access:*:564: pulse-rt:*:557: gdm:*:92: pgsql:*:70: rabbitmq:*:135: _sabnzbd:*:350: squid:*:100: webcamd:*:145:tom Use 'i' to install merged file Use 'r' to re-do the merge Use 'v' to view the merged file Default is to leave the temporary file to deal with by hand *** How should I deal with the merged file? [Leave it for later] As you can see, the new file contains
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Thu, Oct 27, 2011 at 11:22 AM, Thomas Mueller mueller6...@bellsouth.net wrote: I just finished the upgrade from source from 9.0-BETA2 to RC1, and I find two problems. First, I lost my users; nonroot user names are not recognized, if for instance I type passwd arlene I already tried to login as arlene with old password, no good. I copied the /etc directory to a backup on another disk cp -Rp /etc /media/etcbackup-BETA2 and then copied back /media/etcbackup-BETA2/passwd (and group) to /etc but that didn't help. Do I have to recreate nonroot users from scratch? Also, I got a warning about DBUS not starting. When I tried to startx as root, I got into X, but mouse and keyboard were nonfunctional; I did type Ctrl-Alt-F1 and Ctrl-C to get out of X. I think it was the second mergemaster part. Should I, as root and X not running, do mv /etc /etcbackup-RC1 and cp -Rp /media/etcbackup-BETA2 /etc where /media would be mount point for backup partition on USB 3.0 hard drive? The second invocation of mergemaster (after booting single-user) can wreak havoc on /etc . As I type this, I am in my older installation of FreeBSD 9.0-BETA1 but have access to RC1 partition. By the way, /etc/rc.conf remained intact, showing that hald_enable and dbus_enable are still there: hostname=amelia2 keymap=us.iso.kbd ifconfig_re0=DHCP ifconfig_re0_ipv6=inet6 accept_rtadv sshd_enable=YES moused_enable=YES ntpd_enable=YES hald_enable=YES dbus_enable=YES Tom I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. If you still have a backup, you are probably missing just master.passwd. hald, dbus would fail to start since their users are no longer there. Once you've done this to your system once, you never want to do it again! Cheers Tom ___ 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: '/bin/ls' broken by SVN r226509
On Wed, Oct 19, 2011 at 7:47 PM, Anton Shterenlikht me...@bristol.ac.uk wrote: Thanks. Can you also please remind how to reinstall just /bin/ls, without the make buildworld? cp /rescue/ls /bin/ls Cheers Tom ___ 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: no X after installing xorg + xfce
On Tue, Sep 20, 2011 at 12:41 PM, Antonio Olivares olivares14...@gmail.com wrote: The first thing to try is reading the handbook section on configuring X at http://www.freebsd.org/doc/handbook/x-config.html - specifically try running Xorg -configure as root to get a basic xorg.conf file that you can then tweak Once you have this working, you may like to try the binary nvidia driver available from http://www.nvidia.co.uk/Download/index.aspx?lang=en-uk which should provide the all the features of the graphics card Anthony Been there! Done that! Makes no difference. X hangs and returns screen with many lines in colors but X does not work correctly. So thanks for advice, but no that does not help. Maybe what do I have to lose, I should try to rebuild system or reinstall to see if it makes a difference? Regards, Antonio 'Does not work correctly' covers everything from the background the wrong colour to the mouse being inverted and everything inbetween. I've skimmed the thread, (apologies if I've missed it), but I haven't yet seen your Xorg log or your config file. Almost every graphics card should work with VESA at a minimum. With an ancient graphics 'card' like a 6050, x11/nvidia-driver is the wrong driver, you want x11/nvidia-driver-173. However, the 173 series drivers do not support amd64 IIRC. With logs someone may be able to help you, without logs its just shouting out ideas why your X11 installation isn't working. Cheers Tom ___ 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 9.0
On Thu, Sep 15, 2011 at 3:42 PM, Alisson alisson...@gmail.com wrote: Somebody know when FreeBSD 9.0 Releng will be available? http://www.freebsd.org/releases/9.0R/schedule.html Remember that just because a date is in the schedule, doesn't make it a hard date. So I don't know, but sometime soon, when it is ready. Cheers Tom ___ 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: http://www.freebsd.org/marketing/os-comparison.html
On Wed, Aug 31, 2011 at 7:51 PM, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: On 08/31/11 20:13, Garrett Cooper wrote: The list would be way too long. I know other Linux-based groups that have integrated drivers from FreeBSD as well for proprietary work. Thanks, -Garrett And claimed then it's GPLv3? Not that anything is (legally) wrong with that. All code re-use is good - if so many OSes hadn't reused BSD sockets, we probably wouldn't be having this discussion now. Cheers Tom ___ 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: Can't map a Spanish keyboard on Current but in FreeBSD 7.4-STABLE it works fin.
On Sat, Aug 6, 2011 at 12:07 AM, eculp ec...@encontacto.net wrote: I'm running kde on both and 7.4 works equally well with ttys and with kde4-4.6.5. My FreeBSD 9.0-BETA1 works with ttys but not even close with kde4-4.6.5. Is this me or could it be kde or Current? There doesn't seem to be any changes in the language files spanish.iso.acc.kbd, for example. I've been tolerating this for the last week since setting it up with Beta1. Thanks, ed Have you told hald that the keyboard has a different layout? IE, do you have this: $ cat /usr/local/etc/hal/fdi/policy/x11-input.fdi ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input.keyboard merge key=input.x11_options.XkbLayout type=stringes/merge /match /device /deviceinfo Cheers Tom ___ 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 doesnt respect fetch environment settings
2010/6/30 Dag-Erling Smørgrav d...@des.no: Tom Evans tevans...@googlemail.com writes: Sorry to bump this again. I've diluted this issue down to the core points and raised as a pr - can someone take a look, see if my solution is correct and commit if appropriate? Sorry, fell through the cracks. Your analysis is correct, but I'm not 100% sure about the patch. Can you verify that your change does not introduce the possibility of an infinite loop in edge cases? I don't *think* it does, but like I said, I'm not 100% sure and I don't have time to reacquaint myself with the code right now, especially not that particularly nasty part of it :) DES -- Dag-Erling Smørgrav - d...@des.no Like you said, it's quite a large chunk of code to understand. I think you might be right, there could be a situation where a misbehaving proxy server could make it loop. The process is like this: http_auth_challenges_t proxy_challenges struct initialized (line 1497). The flag 'valid' on the struct is initialized to 0 (line 656) We enter the loop for the first time. We dont add proxy auth the first time through the loop, as 'valid' flag not set (line 1586) We receive the reply and switch on the response code (line 1676) If we receive HTTP_NEED_PROXY_AUTH, and the 'valid' flag is not set (implying we didn't send creds), we simply continue to execute the loop (lines 1703 - 1716). This is where the patch I supplied increments the maximum loop counter. The loop now processes the received headers, and when it receives the 'Proxy-Authenticate' header, it calls http_parse_authenticate with proxy_challenges (line 1795) This then populates the proxy_challenges struct, setting the valid flag. Having processed the headers, the loop then checks that receiving a HTTP_NEED_PROXY_AUTH response has resulted in us now having valid flag set in proxy_challenges, otherwise we goto ouch (out of the loop) (line 1806). The loop ends, and we go through again. I thought for a moment while tracing it through that if a misbehaving proxy server sent a 407 response, but did not add a Proxy-Authenticate header, then we could increase the loop counter but without adding any proxy auth, which would mean an infinite loop. However, there is already that sanity check at the end of the loop to check that if we received a proxy authentication error, and still dont have credentials to supply, then we quickly jump out of the loop. I guess that is a little strange, that we could supply proxy auth credentials, but because the server didnt ask for them correctly, we didnt give them - although that would be quite broken behaviour on the part of the proxy server. I think this does show that the patch could be made a little better. We only want to go through the loop one more time if we have credentials to send, and we have credentials to send if the rv of http_parse_authenticate is good. I also think the same bug would affect fetching from servers requiring authentication, so I've made the same fix there as well. New patch attached Cheers Tom Index: http.c === RCS file: /home/ncvs/src/lib/libfetch/http.c,v retrieving revision 1.78.2.5 diff -u -r1.78.2.5 http.c --- http.c 27 Jan 2010 14:54:48 - 1.78.2.5 +++ http.c 1 Jul 2010 13:45:06 - @@ -1786,12 +1786,14 @@ case hdr_www_authenticate: if (conn-err != HTTP_NEED_AUTH) break; - http_parse_authenticate(p, server_challenges); + if (http_parse_authenticate(p, server_challenges)) + ++n; break; case hdr_proxy_authenticate: if (conn-err != HTTP_NEED_PROXY_AUTH) break; - http_parse_authenticate(p, proxy_challenges); + if (http_parse_authenticate(p, proxy_challenges) == 0); + ++n; break; case hdr_end: /* fall through */ ___ 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 doesnt respect fetch environment settings
Sorry to bump this again. I've diluted this issue down to the core points and raised as a pr - can someone take a look, see if my solution is correct and commit if appropriate? http://www.freebsd.org/cgi/query-pr.cgi?pr=148087 Cheers Tom ___ 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: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
2010/6/29 Anton Shterenlikht me...@bristol.ac.uk: On Tue, Jun 29, 2010 at 12:03:39PM +0200, Dag-Erling Smørgrav wrote: Anton Shterenlikht me...@bristol.ac.uk writes: # make buildenv Entering world for ia64:ia64 # env LIBRARY_PATH=/usr/local/lib where does this come from? Your .bashrc or something? I've this set in $HOME/.tcsh. I don't remember why now. I probably fucked up.. However, I've got this set on 3 ia64 boxes. On two of them I don't have this lzma problem. Didn't you mention (about 70 emails previously) that you only had /usr/local/lib/libzma.a on one of your ia64 boxes, and the other two built world just fine? Does that explain why you dont have this problem on those boxes, with the same setting? Cheers Tom ___ 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: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 8:23 AM, Gary Jennejohn gljennj...@googlemail.com wrote: On Wed, 23 Jun 2010 18:15:09 -0700 Ted Faber fa...@isi.edu wrote: (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr commands from cupsd, though it's evidently a bit of a dangerous idea.) [trimmed Cc] I use cupsd and have these settings to get around using the base system lp stuff: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. --- Gary Jennejohn I also have this in make.conf: CUPS_OVERWRITE_BASE=yes WITHOUT_LPR=yes which print/cups-base uses to do make any lpr related binaries in /usr/bin non-executable, so they are skipped over and the cups specific ones in /usr/loca/bin are used instead. WITHOUT_LPR just stops LPR being built by buildworld. Cheers Tom ___ 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: zfs panic
On Wed, Jun 23, 2010 at 10:01 PM, ben wilber b...@desync.com wrote: On Wed, Jun 23, 2010 at 01:47:33PM -0700, Xin LI wrote: panic: _sx_xlock_hard: recursed on non-recursive sx buf_hash_table.ht_locks[i].ht_lock @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/c ommon/fs/zfs/arc.c:1626 Any chance to obtain a backtrace for the panic? From r209229: db:0:kdb.enter.default bt Tracing pid 3233 tid 100396 td 0xff013600f000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x1c8 _sx_xlock_hard() at _sx_xlock_hard+0x93 _sx_xlock() at _sx_xlock+0xaa arc_buf_remove_ref() at arc_buf_remove_ref+0x7b dbuf_rele() at dbuf_rele+0x15d zfs_freebsd_reclaim() at zfs_freebsd_reclaim+0xe1 VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xe8 vgonel() at vgonel+0x186 vnlru_free() at vnlru_free+0x2f4 vfs_lowmem() at vfs_lowmem+0x31 kmem_malloc() at kmem_malloc+0x12c page_alloc() at page_alloc+0x18 keg_alloc_slab() at keg_alloc_slab+0xe6 keg_fetch_slab() at keg_fetch_slab+0x18e zone_fetch_slab() at zone_fetch_slab+0x4f uma_zalloc_arg() at uma_zalloc_arg+0x56b arc_get_data_buf() at arc_get_data_buf+0xaa arc_read_nolock() at arc_read_nolock+0x1cb arc_read() at arc_read+0x71 dbuf_read() at dbuf_read+0x4ea dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x119 dmu_buf_hold_array() at dmu_buf_hold_array+0x57 dmu_read_uio() at dmu_read_uio+0x3f zfs_freebsd_read() at zfs_freebsd_read+0x558 VOP_READ_APV() at VOP_READ_APV+0xe2 vn_read() at vn_read+0x1d0 dofileread() at dofileread+0x97 kern_preadv() at kern_preadv+0x6a pread() at pread+0x52 syscallenter() at syscallenter+0x217 syscall() at syscall+0x39 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (475, FreeBSD ELF64, pread), rip = 0x80100c14c, rsp = 0x7fbfeb48, rbp = 0x2 --- Thanks. I notice the traceback is in the UMA zone allocaor. Did it used to be stable? ZFS recently changed to using the UMA allocator, and I found this made my system less reliable. Does disabling this help? Add this to /boot/loader.conf: vfs.zfs.zio.use_uma=0 Cheers Tom ___ 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: Problem with buildworld with CLANG
On Wed, Jun 23, 2010 at 4:52 PM, Cristiano Deana cristiano.de...@gmail.com wrote: On Wed, Jun 23, 2010 at 3:15 PM, Tom Evans tevans...@googlemail.com wrote: Top of the '[TESTING] Clang..' email: hi, ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import into HEAD in roughly a week. We would like the initial import to be as painless as possible and therefore we ask you to test ClangBSD to assure that the revision we are importing does not have some really embarassing bugs. How to do it (on i386 and amd64): 1) svn co http://svn.freebsd.org/base/projects/clangbsd src i already did it and it worked, two weeks ago. now i wanted to try with clan in system 2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf So uncomment your src.conf lines that are incompatible. forgot to tell before. i tried with and without those lines. The error in your first email was clearly a warning being promoted to an error, so either you had a different error on your build with NO_WERROR/WERROR, or your NO_WERROR/WERROR settings were not being respected. Please retry with NO_WERROR/WERROR set in /etc/src.conf, and show the resulting error. Cheers Tom ___ 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: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 10:21 AM, Andrew Reilly arei...@bigpond.net.au wrote: On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. Since you have /usr/local/bin in your path, why bother with the symlinks at all? Your shell will find them in their new locations just fine. You'll want to remove the old ones from /usr/bin, but make delete-old will probably do that nicely anyway. Cheers, -- Andrew make delete-old removes old deprecated files, not files that weren't built because of src.conf options. It definitely will not remove the lpr binaries from /usr/bin if they exist there. There already is a proper solution for this: if you want to have LPR from CUPS, and don't want to use LPR from base, then you set these settings in make.conf: CUPS_OVERWRITE_BASE=yes WITHOUT_LPR=yes With these, lpr in base will not be built, and print/cups-base will deactivate any base system lpr binaries that are installed. It's documented in the FreeBSD CUPS article here: http://www.freebsd.org/doc/en/articles/cups/article.html#PRINTING-CUPS-PORTS-KNOBS Cheers Tom ___ 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: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 10:45 AM, Alex Dupre a...@freebsd.org wrote: Tom Evans ha scritto: make delete-old removes old deprecated files, not files that weren't built because of src.conf options. I think you are wrong: http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/build/mk/OptionalObsoleteFiles.inc?rev=1.66 -- Alex Dupre Meh, OK. It didn't used to, there was a discussion about this about 6 months ago, and yes, check the history of that file. This support was added in February, nothing in /usr/src/UPDATING about it.. Still, besides the point. There is one supported way to get cups-base lpr used instead of base lpr, and it's got not much to do with 'make delete-old'. http://www.freebsd.org/doc/en/articles/cups/article.html#PRINTING-CUPS-PORTS-KNOBS Cheers Tom ___ 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: Problem with buildworld with CLANG
On Thu, Jun 24, 2010 at 2:33 PM, Cristiano Deana cristiano.de...@gmail.com wrote: On Thu, Jun 24, 2010 at 11:24 AM, Tom Evans tevans...@googlemail.com wrote: The error in your first email was clearly a warning being promoted to an error, so either you had a different error on your build with NO_WERROR/WERROR, or your NO_WERROR/WERROR settings were not being respected. Please retry with NO_WERROR/WERROR set in /etc/src.conf, and show the resulting error. Last lines: /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:135:2: error: unsupported inline asm: input with type 'unsigned long' matching output with type 'unsigned int' R1(D,A,B,C,X( 4), 5,0x5A827999L); ^~~~ In file included from /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:60: /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_locl.h:108:4: note: instantiated from: a=ROTATE(a,s); };\ ^ /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:135:2: note: instantiated from: R1(D,A,B,C,X( 4), 5,0x5A827999L); ^ ~ /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:135:5: note: instantiated from: R1(D,A,B,C,X( 4), 5,0x5A827999L); ^ /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:136:2: error: unsupported inline asm: input with type 'unsigned long' matching output with type 'unsigned int' R1(C,D,A,B,X( 8), 9,0x5A827999L); ^~~~ In file included from /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:60: /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_locl.h:108:4: note: instantiated from: a=ROTATE(a,s); };\ ^ /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:136:2: note: instantiated from: R1(C,D,A,B,X( 8), 9,0x5A827999L); ^ ~ /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:136:5: note: instantiated from: R1(C,D,A,B,X( 8), 9,0x5A827999L); ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 4 warnings and 20 errors generated. *** Error code 1 Stop in /usr/src/secure/lib/libcrypto. *** Error code 1 So thats a completely different error than you had been reporting. I'm afraid I don't know enough about clang to help with that one. Cheers Tom ___ 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: Problem with buildworld with CLANG
On Wed, Jun 23, 2010 at 1:38 PM, Cristiano Deana cristiano.de...@gmail.com wrote: # uname -a FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #3: Tue Jun 22 16:04:38 CEST 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 # cat /etc/src.conf #NO_WERROR= #WERROR= CC= clang CXX= clang++ sources from this morning, i got this error: clang -O2 -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/sys/stack_protector.c /usr/src/lib/libc/sys/stack_protector.c:88:19: error: format string is not a string literal (potentially insecure) [-Wformat-security] syslog(LOG_CRIT, msg); ^~~ 1 error generated. *** Error code 1 Top of the '[TESTING] Clang..' email: hi, ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import into HEAD in roughly a week. We would like the initial import to be as painless as possible and therefore we ask you to test ClangBSD to assure that the revision we are importing does not have some really embarassing bugs. How to do it (on i386 and amd64): 0) install fresh devel/llvm-devel port 1) svn co http://svn.freebsd.org/base/projects/clangbsd src 2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf 3) cd src make buildworld So uncomment your src.conf lines that are incompatible. Cheers Tom ___ 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
Ports doesnt respect fetch environment settings
My company recently enabled proxy authentication for outgoing connections, and this has stopped ports from working. From fetch(5), I understand that I can place my proxy authentication in plain text in the environment*, and this will allow fetch to work correctly, and this does work: # env | grep -i proxy ftp_proxy=http://proxy:3128/ HTTP_PROXY_AUTH=basic:*:tev...@domain.com:password HTTP_PROXY=http://proxy:3128/ # fetch http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz googlecl-0.9.5.tar.gz 100% of 36 kB 77 MBps However, the ports makefiles seem to do something funky to my environment which hides these environment variables, and so the ports infrastructure stops working: # make fetch === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE = googlecl-0.9.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch from http://googlecl.googlecode.com/files/. fetch: http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz: Proxy Authentication Required = Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/. fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/googlecl-0.9.5.tar.gz: Not Found = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/ and try again. *** Error code 1 Stop in /usr/FreeBSD/CURRENT/ports/net/googlecl. This is on i386 7-STABLE, last updated in mid May, with current ports, last updated yesterday. Cheers Tom * Which, incidently, is completely rubbish. Why is there no option for HTTP like ~/.netrc for FTP? Exposing my passwords in plain text in my environment feels stupid. ___ 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 doesnt respect fetch environment settings
On Mon, Jun 21, 2010 at 11:10 AM, Erwin Lansing er...@freebsd.org wrote:
On Mon, Jun 21, 2010 at 11:04:16AM +0100, Tom Evans wrote:
My company recently enabled proxy authentication for outgoing
connections, and this has stopped ports from working.
From fetch(5), I understand that I can place my proxy authentication
in plain text in the environment*, and this will allow fetch to work
correctly, and this does work:
# env | grep -i proxy
ftp_proxy=http://proxy:3128/
HTTP_PROXY_AUTH=basic:*:tev...@domain.com:password
HTTP_PROXY=http://proxy:3128/
# fetch http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz
googlecl-0.9.5.tar.gz 100% of 36 kB 77 MBps
However, the ports makefiles seem to do something funky to my
environment which hides these environment variables, and so the ports
infrastructure stops working:
You should use FETCH_ENV or FETCH_ARGS to pass information to fetch(1) from
the
ports infrastructure. It is documented in /usr/ports/Mk/bsd.port.mk,
search for FETCH_BINARY. Hope that helps.
-erwin
Er, ok that makes slight sense. In /usr/ports/Mk/bsd.port.mk it says:
# FETCH_ENV - Environment to pass to ${FETCH_CMD}.
# Default: none
So how is it picking up that it needs to go thru a proxy at all, given
that this is also only specified in the environment?
Also, am I supposed to literally repeat my same environment variables
in FETCH_ENV? Meaning I have to place my password in plain text again
in my environment? This is horrific...
Also, even after doing that, it still doesn't look at the environment
variables. I prepended -v to FETCH_ENV to show that it is setting
the right environment variables, but fetch in ports is still not
looking at them:
# export FETCH_ENV=-v HTTP_PROXY=$HTTP_PROXY
HTTP_PROXY_AUTH=$HTTP_PROXY_AUTH ftp_proxy=$ftp_proxy
r...@strangepork '11:26:21' '/usr/ports/net/googlecl'
# make fetch
=== Vulnerability check disabled, database not found
=== License check disabled, port has not defined LICENSE
= googlecl-0.9.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
= Attempting to fetch from http://googlecl.googlecode.com/files/.
#env setenv:HTTP_PROXY=http://proxy:3128/
#env setenv:HTTP_PROXY_AUTH=basic:*:tev...@domain:pass
#env setenv:ftp_proxy=http://proxy:3128/
#env executing: /usr/bin/fetch
#envarg[0]= '/usr/bin/fetch'
#envarg[1]= '-ApRr'
#envarg[2]= '-S 37867'
#envarg[3]= 'http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz'
fetch: http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz:
Proxy Authentication Required
= Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/.
#env setenv:HTTP_PROXY=http://proxy:3128/
#env setenv:HTTP_PROXY_AUTH=basic:*:tev...@domain:pass
#env setenv:ftp_proxy=http://proxy:3128/
#env executing: /usr/bin/fetch
#envarg[0]= '/usr/bin/fetch'
#envarg[1]= '-ApRr'
#envarg[2]= '-S 37867'
#envarg[3]=
'ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/googlecl-0.9.5.tar.gz'
fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/googlecl-0.9.5.tar.gz:
Not Found
= Couldn't fetch it - please try to retrieve this
= port manually into /usr/ports/distfiles/ and try again.
*** Error code 1
*.freebsd.org is whitelisted through the proxies, which is why the
second fetch gets a 404 and not a 407
Any thoughts?
Cheers
___
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 doesnt respect fetch environment settings
On Mon, Jun 21, 2010 at 12:07 PM, Gary Jennejohn gljennj...@googlemail.com wrote: Yes. When you ran fetch by hand you didn't have the -ApRr on the CL. Could it be that the 'p' flag is causing problems? Try running fetch by hand again with those flags and see what happens. If it fails, try removing the 'p' flag. -- Gary Jennejohn Yes, I went through the same logic - its not the 'p' flag, its the 'A' flag, which is supposed to prevent it following 302 redirects. In this case, it refuses to retry the request when it receives a 407. # /usr/bin/fetch -ApRr -v -S 37867 http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz looking up proxy connecting to proxy:3128 requesting http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz proxy requires authorization fetch: http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz: Proxy Authentication Required r...@strangepork '12:13:28' '/usr/ports/net/googlecl' # /usr/bin/fetch -pRr -v -S 37867 http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz looking up proxy connecting to proxy:3128 requesting http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz proxy requires authorization looking up proxy connecting to proxy:3128 requesting http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz local size / mtime: 37867 / 1276839258 remote size / mtime: 37867 / 1276839258 That doesn't seem right! Looking in lib/libfetch/http.c it tries to fetch the file in a loop. libfetch first tries without proxy authentication, even if you specify it in your environment. If the request fails due to proxy authentication being required, it sets a flag to add proxy auth details next time through the loop, and continues. If the '-A' flag is set however, it will only go through this loop one time, and so does not attempt to use the supplied proxy authentication. Comments in the source code imply that this is a change in behaviour introduced at the start of the year to support digest authentication; prior to that it would have attempted proxy auth on the first request. The flag for '-A' is documented as: -A Do not automatically follow ‘‘temporary’’ (302) redirects. Some broken Web sites will return a redirect instead of a not‐found error when the requested object does not exist. where as the behaviour is: Do not attempt to download this file more than once, for any reason. Having seen this, the bug is that we wish to go thru the loop one more time to retry with proxy authentication added, but the loop may exit on the next iteration. This diff allows it to go through the loop one more time, and now fetches the file correctly. Incidentally, having fixed fetch to work with '-A' thru a proxy that requires proxy auth, I now dont require anything in FETCH_ENV or FETCH_*_ARGS, it works correctly with the PROXY_* environment variables. Patch attached. Cheers Tom Index: /usr/src/lib/libfetch/http.c === RCS file: /home/ncvs/src/lib/libfetch/http.c,v retrieving revision 1.78.2.5 diff -u -r1.78.2.5 http.c --- /usr/src/lib/libfetch/http.c27 Jan 2010 14:54:48 - 1.78.2.5 +++ /usr/src/lib/libfetch/http.c21 Jun 2010 11:30:32 - @@ -1710,6 +1710,7 @@ goto ouch; } /* try again, but send the password this time */ + ++n; if (verbose) fetch_info(proxy requires authorization); break; ___ 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
GrandCentralDispatch in FreeBSD?
Hi Robert I saw today that you've written a proof of concept MPM for apache in GCD [1] - are there any plans to port GCD to FreeBSD? Cheers Tom [1] http://lists.macosforge.org/pipermail/libdispatch-dev/2010-May/000352.html ___ 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: kmem_map too small: 3832475648 total allocated
On Thu, Apr 29, 2010 at 3:53 PM, Ollivier Robert robe...@keltia.freenix.fr wrote: According to James R. Van Artsdalen: system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12 GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB. panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated Apart from the fact that you must at least set vm.kmem_size to something like 2x your RAM, one rule of thumb I've seen discussed for ZFS is that you will need approximatively 1 GB of RAM per TB of data so you may be a bit short here to get optimal perfs. Citation needed? I have a file server running amd64 8-STABLE with 4GB of RAM, 6 x 1.5 TB drives in raidz, and have never had any problems with memory usage. Are you saying that after my next update, adding another 6 x 1.5 TB drives, it will start being flaky and/or panicing with kmem_map too small errors? Cheers Tom ___ 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+world / ports make options
On Sat, Apr 24, 2010 at 5:42 PM, Pegasus Mc Cleaft k...@mthelicon.com wrote: Hello Hackers Current, I was wondering it if is possible, or if it can be done so a separate set of CC, CXX, etc can be specified for building the world and kernel independently of a ports build? Right now, I use the base GCC to compile the world and kernel, and GCC44 for most of the other ports (when it complies cleanly). But I have to keep editing the /etc/make.conf file to switch between the two. It may already be implemented, but it would be nice if there was something defined while the kernel and/or world is being built to that a nested block of ifdefs can select which env variables to be set. Peg man src.conf Cheers Tom ___ 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: ISO9660 4GB directory structures boundary limit and growisofs
On Mon, Apr 19, 2010 at 1:48 PM, Paul B Mahol one...@gmail.com wrote: On 4/17/10, Paul B Mahol one...@gmail.com wrote: On Sat, Apr 17, 2010 at 4:31 PM, Tim Kientzle kient...@freebsd.org wrote: Paul B Mahol wrote: It is apparently not possible to make use of -use-the-force-luke=4gms on FreeBSD when appending new session after 4GB. Mounted disk afterwards show nothing. Should we allow it like linux does? Are you claiming there is a problem when FreeBSD reads such images or a problem with creating such images? What programs are you using? I burn flac files in multiple sessions, each session have separate directory, on DVD+R DL MKM/003 After I used 4gms switch mounted fs shows nothing. (but there is 5GB of data) According to growisofs source BD (bluray) dont need this switch at all ... This sounds like a pretty unsurprising 32-bit truncation bug: the filesystem structures in ISO9660 are all sector numbers so 8TB should be the natural limit (4G sectors times 2k bytes/sector). I did not tested this on FreeBSD amd64 yet. Update: Linux shows all sessions and Windows 7 shows only first one. From the source code of groisofs.c: * - DVD+R Double Layer support; * - -use-the-force-luke=4gms to allow ISO9660 directory structures * to cross 4GB boundary, the option is effective only with DVD+R DL * and for data to be accessible under Linux isofs a kernel patch is * required; So I'm guessing it does something non standard, particularly if windows also refuses to see the data. Cheers Tom ___ 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: When will we can use ZFS v24?
On Fri, Apr 9, 2010 at 6:44 PM, Dan Nelson dnel...@allantgroup.com wrote: In the last episode (Apr 08), Garrett Cooper said: On Thu, Apr 8, 2010 at 2:30 PM, Chuck Swiger cswi...@mac.com wrote: On Apr 8, 2010, at 2:18 PM, krad wrote: [ ... ] is that even possible with CDDL? im not a lawyer but it wouldn't surprise me I'm not a lawyer either, but I was active in reviewing and suggesting changes to CDDL submission for OSI approval back in 2004. A copyright owner always has the ability to relicense their code under other terms, but existing code is guaranteed to be available, redistributable to others, etc under the terms of the current version of CDDL; in particular see: If Oracle chooses, they might make future changes to the ZFS source code under different or more restrictive licensing terms, but what's available now is always going to be available. The same of basic principle applies to BDB; originally it was BSD licensed in 1.x under FreeBSD, then GPLed in 2.x+ (IIRC), then left to pasture in 4.x after Oracle acquired Sleepycat DB. MySQL is GPLv2 today... who knows what it might be tomorrow... BDB was never GPL'ed; it was and still is BSD-licensed. http://www.oracle.com/technology/software/products/berkeley-db/htdocs/oslicense.html IANAL, but that is not a BSD license. It is the Sleepycat license, which is compatible with GPL. The giveaway is in section 3: * 3. Redistributions in any form must be accompanied by information on *how to obtain complete source code for the DB software and any *accompanying software that uses the DB software. The '.. any accompanying software' clause makes it quite like the GPL. Cheers Tom ___ 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
