Re: service -e doesn't really sort does it? the cool tip is slightly off
On Sat, 16 Jan 2021 23:28:48 + Dennis Clarke wrote: > Saw this pop up : > > rhea$ su - admsys > Password: > If you want to get a sorted list of all services that are started when > FreeBSD boots, > enter "service -e". > ... > > To which I thought "sorted? really?" > .. > Nope. That doesn't look sorted. Unless the sorted means "order in > which they start" perhaps. To me that's the obvious interpretation of 'sorted' because it's the only meaning that's relevant to the context. If it simply meant alphabetical order, it wouldn't have been worth mentioning. In any case, it's clear in service(8). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Thu, 31 Dec 2020 21:25:08 -0500 grarpamp wrote: > > Is there any reason to think [bittorrent] insecure? > > Cost under $50k of compute to break sha-1, AFAIK you cannot break SHA-1 in the sense of creating data that matches a specific hash. What you can do is create a collision between two blocks of data, varying both blocks in the process. This makes SHA-1 unsuitable for digital signatures. A *third-party* attacker cannot create a bogus torrent using a collision attack against SHA-1 because the attacker would need to match a specific hash value. What may be possible is that the creator of the legitimate torrent might create two torrents with the same hash, but this seems very contrived and not very useful. It has all sorts of problems as a way of delivering targeted malware. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Thu, 31 Dec 2020 11:39:08 -0800 John-Mark Gurney wrote: > grarpamp wrote this message on Wed, Dec 30, 2020 at 00:55 -0500: > > > signatures of the magnet links > > > > Signing torrent.asc, with stronger or even same hash as BT > > protocol, still serve purpose of authenticate torrent file back > > to a signer to the degree therein, caveat their platform security, > > caveat sha-1 inside torrent still being abuseable by third party, > > caveat etc > One of the large parts of security is that not everyone knows the > in's and out's of security, so people who don't know, will have heard > that SHA-1 is a cryptographic hash, and assume that something is > secure when using it. Is there any reason to think it's insecure? Even if a collision attack can be make to work against bittorrent, the attacker would need to have control over the contents of the legitimate torrent as well as the bogus one. It wouldn't be "abuseable by third party". ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Reducing UFS corruption from unclean shutdowns?
On Fri, 21 Jun 2019 13:49:30 -0600 Alan Somers wrote: > I panic my development VM regularly. Each time, I need to fsck the > file system. I've found UFS on gjournal to be reliable. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "arc4random: no preloaded entropy cache" printed once per CPU on startup
On Sat, 27 Oct 2018 16:38:00 -0600 Rebecca Cran wrote: > On a normal boot (not verbose) of -CURRENT from today's sources I'm > getting the following message printed once for each logical CPU: > > > arc4random: no preloaded entropy cache > > > Since other messages, including the same one in random_harvestq.c are > under bootverbose, should this one in arc4random.c be too? > > > I guess another question is _why_ this message is being displayed, > since it looks like it should only happen if an entropy stash > (/entropy?) is missing: /entropy is the old style file fed into /dev/random from rc.d/random. There's another file /boot/entropy which is read much earlier. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd as ntpd user question
On Sat, 21 Jul 2018 12:02:19 -0700 Cy Schubert wrote: >> I wish mergemaster had an option to just add new users and groups, >> rather than merging the files. > What's the difference? It would be automatic, so less hassle and no chance of getting the merge wrong. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd as ntpd user question
On Sat, 21 Jul 2018 11:14:45 -0600 Ian Lepore wrote: > There's a "pre-world" stage of mergemaster (-Fp option I think) which > isn't needed often, but one of the times it is needed is apparently > when new user ids are added. I wish mergemaster had an option to just add new users and groups, rather than merging the files. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A question about updating src & ports
On Thu, 29 Dec 2016 18:11:38 +0800 blubee blubeeme wrote: > Can I mix portsnap fetch update or should I just continue to use svn > update /usr/ports As a general rule don't mix methods in the same directory. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: release name
On Sun, 31 Jul 2016 18:41:20 + (UTC) Kostya Berger wrote: > Could somebody, please, explain this: > Am I right to assume that CURRENT or "head" release number is now > 12.0?For in that case I'll have to reduild the ports in case of > upgrading my system to the current head, right?Because my current > system was build well before the 11.0-alpfha releases statred > appearing. With stable branches and releases you rebuild ports when crossing a major boundary because that's the only time ABI changes can break packages. With CURRENT the ABI can change, and break packages, at any time. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Oversight in /etc/defaults/rc.conf
On Tue, 12 Jul 2016 15:10:43 +0100 Matthew Seaman wrote: > I'm not religious about it being turned off per se. More that it > should have a clearly defined on/off state shown in the defaults. > > I went for 'off' following the general principle that rc.conf items > should mostly be off by default and require specific action to enable. > Yes, there are exceptions to this rule, but I see no particular reason > that iovctl should be one. What's the advantage to turning it on by > default on every FreeBSD installation? Unless I'm misunderstanding the situation. rc.d/iovctl isn't actually doing anything by default because of iovctl_files="". There is an analogy with rc.d/sysctl which runs by default, with a an empty sysctl.conf file. This also has no explicit enable entry in rc.conf. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: how to recycle Inact memory more aggressively?
On Sat, 12 Mar 2016 09:38:35 +0100 Gary Jennejohn wrote: > In the course of the last year or so the behavior of the vm system > has changed in regard to how aggressively Inact memory is recycled. > > My box has 8GB of memory. At the moment I'm copying 100s of gigabytes > from one file system to another one. > > Looking at top I observe that there are about 6GB of Inact memory. > This value hardly changes. Instead of aggressively recycling the > Inact memory the vm now seems to prefer to swap. Paging-out is a side-effect of processing inactive memory. As the inactive queue is recycled a small number of pages can get copied out to swap with the contents remaining in memory. If you turn this off, the writes to can end up being done while something is waiting, rather than in the background. A small amount of swap in use is normal. If you see a large amount then check for memory leaks and unwanted files on tmpfs. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?
On Thu, 18 Feb 2016 14:16:24 +0100 O. Hartmann wrote: > Hello out there, > > I run into a problem and digging for a solution didn't work out. > > Problem: I need a string that reflects the hashed password for the > usage with > > passwd -H 0 Did you mean -h? > I think the procedure is using > > sha512 -s Password > > and using this output for further processing, but how? It's not as simple as that, password hashes are usually salted and iterated. Salting means that the password is combined with a randomly generated string stored in plaintext, which means that the password doesn't hash to a fixed string. I'm not sure exactly what you are trying to do, but crypt(3) may be of help. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Depreciate and remove gbde
On Mon, 19 Oct 2015 06:19:30 +0200 O. Hartmann wrote: > When I looked for FreeBSD's encryption, I stopped by GELI. Because of > it's easy-to-use AND the 'experimental' tag in the handbook! > > For me, I'd like to know what is the benefit/performance of each > technique and a clear preparation of each ones advantages over the > other. IIRC gbde allows the passphrase to be verified even after the master-keys have been deleted. The point is to demonstrate that the passphrase is not being withheld, and the data unrecoverable. AFAIK that's the only advantage it has over geli. geli supports hardware acceleration, it's faster in software too. It's more resistant to dictionary/brute force attacks against the passphrase because of its PKCS #5 support. It supports a wider range of options and ciphers/modes. And though it's newer, it's undoubtedly had far more user-hours of use. Also I don't remember the details, but I think there's an operation that's atomic in geli, but not in gbde, that gives gbde a greater risk of data corruption. I certainly wouldn't like to see gbde removed but I think it is unfortunate that it's given slightly greater prominence in the handbook than geli. geli is the right choice for most people. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: default pager (csh)
On Fri, 20 Feb 2015 14:18:24 +1030 Shane Ambler wrote: On 20/02/2015 01:22, RW wrote: On Wed, 18 Feb 2015 19:16:59 -0600 Mike Karels wrote: Trivia: the version of more on BSD systems actually is derived from less, not the original version of more. Actually, more is less $ md5 -r `which less ` `which more ` 50404f1beaa4e1261407190a88494b59 /usr/bin/less 50404f1beaa4e1261407190a88494b59 /usr/bin/more Yes more has been less for some time, trouble is it is programmed to behave differently based on the name used to call it so they aren't the same. I'm aware of that. Like everything, if you don't like the way it works you find a setting to make it work the way you want. Whether you ask on a mailing list or google it you will find a way to configure it your way. As long as it works, the default is of little concern to most. Whatever the choice of default pager, I think the defaults should be set-up so man doesn't exit at the bottom of a page. The fact that it's easy to change make it all the more obtuse have a default that's awkward for new users who want to read the documentation. ___ 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: default pager (csh)
On Wed, 18 Feb 2015 19:16:59 -0600 Mike Karels wrote: Trivia: the version of more on BSD systems actually is derived from less, not the original version of more. Actually, more is less $ md5 -r `which less ` `which more ` 50404f1beaa4e1261407190a88494b59 /usr/bin/less 50404f1beaa4e1261407190a88494b59 /usr/bin/more ___ 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-update install failed
On Fri, 24 Oct 2014 19:23:00 +0200 d...@gmx.com wrote: Allan Jude wrote on 10/24/2014 18:29: Do you have a src tree installed? Obviously not. It's not at all obvious. caused by it trying to install the update to an empty src tree, so the contrib/tzdata parent directory does not exist. It is a minor problem with freebsd-update where it gets confused the odd time a new file has to be added in a security update. It is a problem with the update package, actually. To update /usr/src, one should use Subversion. Not? If it is the job of freebsd-update to update /usr/src (when it exists), then freebsd-update should also try to apply source code security patches as well, which apparently is not the case. freebsd-update can update /usr/src, it depends how it's set-up in freebsd-update.conf ___ 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: geli TRIM support
On Thu, 20 Mar 2014 19:34:04 + Mike C. wrote: I was actually googling about this yesterday and found no more info then the thread you posted. So its seems that nothing was done related to this so far? Which means using trim+geli is problematic. These days SSD devices have static wear-levelling so you don't need to maximize the number of free blocks, just maintain a small pool. You can do that by not partitioning the whole device and leaving a few percent unused. I'm not sure what you would do if the device had already been written to though, if FreeBSD has a command to trim a device I don't know what it is. You could just use Linux's hdparm from a live CD. You should also be OK if you have a non-geli UFS partition with sufficient free space on the same device. I was using my ssd with UFS+trim+geli in my laptop. But even before noticing the lack of support changed my setup... since the laptop has both a ssd and hdd I am now using zfs+geli in the hdd. I have 2 partitions in the ssd and I'm using it for log/cache. I've been considering that, but I did have a couple of concerns: 1. l2arc sounds like it would be much less effective outside of servers because, AFAIK, the cache doesn't survive a reboot. 2. the l2arc cache turns reads on the filesystem into writes to the SSD. ___ 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: gnash broken
On Sun, 16 Mar 2014 17:07:32 + (UTC) Thomas Mueller wrote: Maybe build and install wine and download 32-bit Adobe Flash plugin? Wine only runs on i386 but can be run from amd64 using /compat/i386. The Linux Flash plugin still works for me. ___ 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, 7 Mar 2014 09:13:30 -0500 John Baldwin wrote: 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. I'd expect it to be done well in advance of that to give plenty of time for the transition. We are talking about brute force attacks and GPU development is relatively predicable. And lets not lose sight of the fact that we are only talking about limited mitigation after an attacker has gained root access, not front-line security. 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. Whenever I've been required to change passwords it's always been imposed immediately after a login. Just locking-out an account sounds very heavy-handed to me. It seems like it would be trivial to extract a list of accounts using the old-style hashes from master.passwd - at least that way you can send them an email. ___ 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: Import of DragonFly Mail Agent
On Mon, 24 Feb 2014 19:24:02 -0500 (EST) Benjamin Kaduk wrote: On Mon, 24 Feb 2014, Lyndon Nerenberg wrote: What would really help is if the ports fetch-recursive-list target could extend to reliably include the distfiles for the runtime dependencies as well. But I'm not even sure that's possible. We tried a few different things, but in the end we had to brute force it by running 'make fetch' in every one of the ports directories in order to get all the distfiles onto an external system, which we then rsynced to a USB drive, marched inside, and rsynced to the fileserver. Not pretty ... but with all the distfiles at hand we knew the inside ports builds wouldn't fail due to missing dependencies. I'm rather confused by why it isn't working for you. http://svnweb.freebsd.org/ports/head/Mk/bsd.port.mk?revision=345884view=markup#l5187 is quite clearly looking in ALL-DEPENDS-LIST, which includes runtime dependencies. The only thing I can think of is that non-default configurations are in play, so that 'make config make config-recursive' should be (re-)run until it does not prompt, and only then fetch-recursive-list be used. One oddity is that fetch-recursive-list generates a script that downloads all the files into the current directory. It doesn't take account of the fact that some ports look for their files are in a sub-directory. ___ 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-update
On Thu, 30 Jan 2014 12:07:26 +0100 Lars Engels wrote: FWIW, the performance problems with proxies are limited to HTTP proxies which don't speak HTTP/1.1. Are you sure? I just tried it manually with telnet: ... IIUC the proxy itself supports HTTP/1.1 but not the webserver behind the proxy? That's the same proxy that takes hours to download the patches with httpget. Proxy support for HTTP/1.1 on the client side doesn't imply that it supports full end-to-end pipelining. The proxy can advertise 1.1 without supporting pipelining. Even if it does that doesn't necessarily imply that it has full end-to-end pipelining. I'm not sure what the current state of squid is, but for years it translated client side HTTP 1.1 pipelining into individual HTTP 1.0 requests on the server side. I don't use freebsd-update myself, but from a quick look at the manpage I think it could benefit by extending the cron command to allow fetching a new release automatically. ___ 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: Official FreeBSD Binary Packages now available for pkgng
On Sat, 02 Nov 2013 12:28:06 + Matthew Seaman wrote: Which is not always true, especially in heavily firewalled environments. I feel no obligation to do anything to encourage people that deliberately break the DNS. They've made their bed, and now they have to lie in it. In other words, one more reason to choose Linux. You can only afford to say no soup for you if you're the only soup-nazi in town. I think there's an important distinction between broken dns and local dns. If someone wants to provide controlled web access through a web cache without giving general internet access then I don't see why they shouldn't. This doesn't affect admins running servers, it affect people trying to install FreeBSD on the locked-down part of the network - typically the desktop machines of developers. It also seems to be a fundamentally bad idea for a client that knows it's connected to a proxy to be choosing the server in the first place. ___ 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: May you please add alias for nslookup?
On Sat, 12 Oct 2013 10:44:56 +0200 Ivan Voras wrote: explaning the user what has happened and optionally invoking host or dig. Actually dig has gone and has been replaced by the unbound utility drill. ___ 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: claws-mail deadlocking in iconv
On Wed, 9 Oct 2013 18:34:46 +0200 Fabian Keil wrote: After the iconv import claws-mail started to deadlock in iconv every now and then on my system, which prevented claws-mail from rendering windows or reacting to input. ... and I'm also a bit surprised by the lack of reports from other claws-mail users. Did anyone else run into this or can comment on the patch or the backtraces? I can't comment on the rest, but I have recently been seening lock-ups in claws-mail on current. ___ 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: sysctl: unknown oid 'kern.random.sys.harvest.interrupt
On Sat, 21 Sep 2013 11:14:29 +0800
Alastair Hogge wrote:
On 2013-09-16 Mon 19:21:39 +0200, Joel Dahl wrote:
Hi,
Hi,
I noticed the following during boot on a machine running HEAD from
today:
I have noticed this since the recent work to /sys/dev/random
Entropy harvesting:sysctl: unknown oid
'kern.random.sys.harvest.interrupt': No such file or directory
interruptssysctl: unknown oid 'kern.random.sys.harvest.ethernet':
No such file or directory ethernetsysctl: unknown oid
'kern.random.sys.harvest.point_to_point': No such file or directory
point_to_point kickstart.
Known problem?
It looks like /etc/rc.d/initrandom is no longer correctly checking for
whether the software generator is in use, so it tries to set sysctls
that don't exist. Those partiticular warnings look harmless.
It might be that writing to /dev/random which occurs immediatly after is
causing the problem. Try commenting out the following:
# First pass at reseeding /dev/random.
#
case ${entropy_file} in
[Nn][Oo] | '')
;;
*)
if [ -w /dev/random ]; then
feed_dev_random ${entropy_file}
fi
;;
esac
better_than_nothing
___
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 with daemons on uninstall...
On Mon, 15 Jul 2013 08:34:05 -0500 Mark Felder wrote: On Sun, Jul 14, 2013, at 14:49, Garrett Wollman wrote: Strongly agreed -- and it's what other operating systems do, either by policy or by convention. As long as this behavior only happens during pkg installs and never with ports, I'm OK. The worst is when a coworker forgets that the mysql port stops the daemon and my coworker upgrades with portmaster... the daemon is off the entire time mysql slowly compiles... Is that really correct? I would expect the deinstall to be done after the build has completed successfully. ___ 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
