Re: smartmontools and update-smart-drivedb

2020-04-29 Thread Dan McGrath
Hi,

On Wed, Apr 29, 2020 at 11:20 AM Bob Eager  wrote:

> The port doesn't get updated every time there is a new drive database;
> that would be unworkable.
>

Just a thought, but perhaps something similar to what ntp does with:

  service ntpd fetch

But of course using smartd, so that it can fetch something upstream?

-- 
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: qt5-webengine

2020-04-05 Thread Dan McGrath
On Sat, Apr 4, 2020 at 7:43 PM Robert Huff  wrote:

> I understand there are folks for whom poudriere or synth are The
> Right Tool(tm).  But I am one of a number of folks for whom it is like
> carpet-bombing the neighborhood to get rid of one miscreant squirrel.
>

I swear, you find that squirrel you phone me asap! I have the warthogs
circling looking for him for at least a week now!


-- 
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Alternatives to security/swatch

2020-03-16 Thread Dan McGrath
Hi,

Just a heads up that I also had bug report #243609 [1] open on this that I
guess can/should be closed now.

Dan

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243609

On Mon, Mar 16, 2020 at 3:57 AM Guido Falsi via freebsd-ports <
freebsd-ports@freebsd.org> wrote:

> On 15/03/20 18:09, Andrea Venturoli wrote:
> > Hello.
> >
> > I'm using security/swatch to look *in real time* for specific strings in
> > my logs, but now it's deprecated because it's unfetchable.
> >
> > Can someone suggest an alternative?
> >
> > N.B. I'm not looking for something that will parse logs at specified
> > times (e.g. run from cron); I already have logcheck.
> > I'm using swatch, in addition to that, to look for things that require
> > immediate attention, by piping syslogd into it.
> >
> > Bonus for not requiring too many dependencies :)
>
> In the past I've used misc/logsurfer for such purpose.
>
> I'm not using it anymore since I'm now using fail2ban for the purpose.
> BTW it also does monitor log files in real time and with clever
> programming could also work as a notification system, but I agree that's
> not it's primary purpose.
>
> --
> Guido Falsi 
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>


-- 
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Starting with poudriere

2020-02-16 Thread Dan McGrath
Hi,

On Sun, Feb 16, 2020 at 10:51 AM Grzegorz Junka  wrote:

> Just a note that this is not a strict requirement. I have been upgrading
> from FreeBSD 9 to 12 currently and was always building on the same
> system that I am deploying to. Yes, poudriere will complain that the
> jail is newer than the base system, but that did not create any major
> practical problem for me yet.
>
> I think only on one occasion I got a build error due to missing symbols.
> Then the solution for me was to upgrade the base system. This of course
> broke the applications that were installed for the older base, but
> thanks to the FreeBSD's separation of base from ports, it's still
> possible to start FreeBSD with just the command line. Then I finished
> building the ports and reinstalled them.
>
> Not that I encourage this approach, it might create additional issues to
> solve, but it is possible/manageable and shouldn't be held against using
> poudriere.
>

Ah, good to know. It's been a long time now since I ran into that, so I was
a little hazy on the details of the error.

I love the separation of FreeBSD from ports, and indeed, being able to
recover from broken userland is nice, although I hate the days where I
remove libs first, then try run sudo, and have to go in via BMC. Worse is
if you have a critical website down. Especially if you have to stop and
spend a bunch of time compiling ports before you go live! :D Also, tex and
llvm, wtf is with those build times?! heh

Anyway, thanks for clarifying!


Cheers,

Dan McGrath
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Starting with poudriere

2020-02-15 Thread Dan McGrath
Hi,

On Sat, Feb 15, 2020 at 11:03 PM @lbutlr  wrote:

> Let’s say I want to build and install a single port via poudrier. For the
> same of argument some port that has configuration options I want to change.
>

Probably not ideal since you generally want to disable the FreeBSD
repository, and use only your poudriere repo, instead. You would need to
build everything you intend to install in the jail, however. While I
believe that you can enable multiple repositories (FreeBSD's, and your own
poudriere one), I am not sure about repo priorities, or how you would deal
with conflicts with build options that pull in common ports. It is
something I have been meaning to look into, sorry! Perhaps someone else
here can give some advice?


> I have the ports tree setup, have my jail setup, and I want to build it.
>

You would run "poudriere bulk", then sit back sipping coffee while it
churns through all of the packages.


> And then I want to deploy it to the target machine once it’s built.
>

I personally make a web server on the jail to serve up the path to the
packages that poudriere built, generally available under:

/usr/local/poudriere/data/packages



> Or I want to deploy to to the local machine.
>

I suppose you could "bind mount" (see: man nullfs) the path into the jail,
or just specify the file path as a URI to the poudriere.conf pkg config.


> Let’s say, for fun, it’s something like ImageMafick that has a lot that
> goes with it.
>

Poudriere takes care of the dependencies. For example, if the _only_ thing
that you want in your jail is ImageMagick, as if you literally boot
strapped a blank jail, then ran "pkg install ImageMagick", then you would
only need to built that, and pkg, in poudriere. Your build set file would
probably look like this:

ports-mgmt/pkg
graphics/ImageMagick7-nox11


I would have to actually double check if pkg is even needed since I believe
it may be implicitly depended on, in which case it would already be built,
but I appear to have it specified in all of my sets anyway.


> Am I writing a config file for this every port I want to build?


You would create a file for all the leaf ports for the repository that you
want to create for your machines to use. I generally will do something like
install portmaster in a jail, then install all of the stuff I want, then
use something like "portmaster -L" (requires /usr/ports to be available) to
identify the root and leaf ports. Then I will place all of those files into
the file I pass (via -f) to poudriere to build. Poudriere will take care of
all the dependencies, and will leave you with a repo that has exactly
everything you need to install.

Anyway, hope this maybe helps a bit? Since flavours have came out, I have
been slowly trying to avoid using custom repos, and try migrate things to
stock upstream packages. While it is fun to tinker with, the amount of time
I have wasted over the years doing buildworld and building ports by hand
has made me start to look at more practical approaches, such as pkg's and
freebsd-update. Unless you have trust issues with upstream binaries, or
require unusual build options, I think it may not be worth using poudriere,
and perhaps better to convince upstream to add flavours? Just a thought!


Cheers,

Dan McGrath
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Starting with poudriere

2020-02-15 Thread Dan McGrath
Hi,

Just a bit of a heads up that poudriere will require you to be on the new
version of FreeBSD before you can build for it on the current system. For
example, if you are running 12.1, and you upgrade poudriere's jail to 13.0,
it will complain that you have to be running that version on the host you
are using it on. Ideally, poudriere should be running on it's own dedicated
system, not the one you intend to deploy to.

As for how I use it here, I use salt to deploy to the poudriere machine,
with one repo per host/jail. It's been good, but things get very hairy with
this approach since all of the ports need to be recompiled whenever you
update the jail (say from 12.1-RELEASE-p1 to 12.1-RELEASE-p2). When you
start to have multiple port trees, multiple jails and multiple sets, the
permutations of this start to really kick you in the face :) I built on a
tiny old quad core VM, which makes matters worse.

In terms of how I actually use things, originally I started off doing
"poudriere options ...", and would go through pressing enter for every menu
config option, and for each repo (host/jail) that I have. This was a pain,
especially during quarterly changes where the on disk files in
/usr/local/etc/poudriere.d/ for each -- directory would
have to be copied to a new filename in order to start from the previous
settings, and then change what is new etc. Eventually I learned that I
could just erase all that, skip the "poudriere options", and specify the
defaults that I want/need to override in the
/usr/local/etc/poudriere.d/make.conf file. That I could specify options per
port, as needed with something like this:

OPTIONS_SET+= GSSAPI_NONE
OPTIONS_UNSET+= CUPS DBUS X11 DOCBOOK EXAMPLES KERBEROS PERFSCHEMA PERFSCHM
GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_MIT WAYLAND OPENGL XCB
DEFAULT_VERSIONS+= ssl=openssl
# Python
DEFAULT_VERSIONS+= python=3.7 python3=3.7
# Ensure apache uses event MPM or ZTS will disable and php extensions will
fail
# to build inside poduriere!
WITH_MPM=event
# Apache 2.4
www_apache24_UNSET+= MPM_PREFORK MPM_WORKER
www_apache24_SET+= MPM_EVENT
# Ensure ZTS
www_mod_php72_SET+= ZTS
lang_php72_SET+= ZTS


That should get you an idea how to setup the make.conf, at least. With this
approach, I don't have to deal with the headaches of going through millions
of menu options every time stuff changes. While I still need to migrate to
more of a "single repo" approach, it is nice having dedicated repos for
each jail, but it does mean that you are compiling the same stuff over and
over, so be warned! Interesting note was that I originally had ccache
installed in the system, and even with SSD's over network storage, was
finding that the I/O was actually adding to my compile times, so I just
disable it now.

As for your question of the file to use to build a bunch of ports, the
approach I use is a layout like this:

/poudriere/
/poudriere/113amd64
/poudriere/113amd64/2019Q4
/poudriere/113amd64/2019Q4/host_a
/poudriere/113amd64/2019Q4/host_b
/poudriere/113amd64/2020Q1
/poudriere/113amd64/2020Q1/host_a
/poudriere/113amd64/2020Q1/host_b
/poudriere/113amd64/bulk-2019Q4.sh
/poudriere/113amd64/bulk-2020Q1.sh
/poudriere/113amd64/clean-2019Q4.sh
/poudriere/113amd64/clean-2020Q1.sh
/poudriere/121amd64
/poudriere/121amd64/2019Q4
/poudriere/121amd64/2019Q4/host_a
/poudriere/121amd64/2019Q4/host_b
/poudriere/121amd64/2020Q1
/poudriere/121amd64/2020Q1/host_a
/poudriere/121amd64/2020Q1/host_b
/poudriere/121amd64/bulk-2019Q4.sh
/poudriere/121amd64/bulk-2020Q1.sh
/poudriere/121amd64/clean-2019Q4.sh
/poudriere/121amd64/clean-2020Q1.sh
/poudriere/bulk-all.sh
/poudriere/update-2019Q4.sh
/poudriere/update-2020Q1.sh


Where the bulk-all.sh script just runs the bulk-.sh and clean
scripts. As sample of one of them would be:

#!/bin/sh

#
# Because variables
#
JAIL="113amd64"
TREE="2020Q1"
LIST_PREFIX="/poudriere/${JAIL}/${TREE}"

# Bulk compile
for lcv in ${LIST_PREFIX}/*; do
echo "Bulk for $lcv..."
#read -p "Press ENTER to continue. " INPUT
nice poudriere bulk -j $JAIL -p $TREE -z $(basename ${lcv}) -f
"${lcv}"
done


Of course, the clean script would replace s/bulk/clean/, but you get the
idea. More of a prototype script than anything, but it "works", although
could most certainly be done better!

Hopefully this gives you a bit of insight and understanding into the
system, and possible approaches to setting things up. Best of luck! o/


Cheers,

Danny McGrath

On Sat, Feb 15, 2020 at 6:33 PM @lbutlr  wrote:

> I’ve setup a new FreeBSD 12.1 system and am going to give poudriere a
> whirl on it.
>
> The machine is currently setup as a two drive zfs mirror and I have used
> pkg to install a few basic things (sudo, zsh, poudriere itself, etc).
>
> I am reading through <
> https://wiki.freebsd.org/VladimirKrstulja/Guides/Poudriere#A3._Create_the_list_of_ports_wanted_in_the_repo>
> and I have some questions.
>
> First, the example of says that if we don’t change any options, the
> defaults will be used. OK, but it 

security/openssl: 1.1.1d in 2020Q1 still vulnerable?

2020-02-05 Thread Dan McGrath
Hi,

Was just noticing that the 2020Q1 port for OpenSSL was still showing up
with 11 different CVE's, yet I noticed that the commit [1] in r511808 says
it fixed 9e0c6f7a-d46d-11e9-a1c7-b499baebfeaf, yet it still shows up in pkg
audit for CVE-2019-1549 and CVE-2019-1547.

Any idea what the story is here?

[1] - https://svnweb.freebsd.org/ports?view=revision=511808


Thanks,

Danny McGrath
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"