Re: Using outside values in a Portfile tcl
Agreed, but then using other strings such as ‘macportshost’ instead of ‘host’
would make it a lot easier to find where they have been used so you know what
to change. Host domain and tld are so generic it makes it more difficult to
discern what has been the result of basic config.
Gerben Wierda
Chess and the Art of Enterprise Architecture
Mastering ArchiMate
Architecture for Real Enterprises at InfoWorld
On Slippery Ice at EAPJ
On 21 Sep 2019, at 02:45, Steven Smith wrote:
> > obviously, my system isn’t called host.domain.tld or the relayhost
> > mymailrelay.tld.
>
> Please refer to `port notes mail-server`:
>
> “Users must reconfigure this installation for their own system, network, and
> security model specifics by editing all necessary files and checking file
> permissions.”
>
> A deployed mail server will require many changes to the example working
> configuration provided in the mail-server port: TLS, DKIM, DNS, SPF, DMARC,
> possibly a mail relay, and more. Use the MacPorts configuration as a working
> basis to start from and edit the configuration for your own deployment. Users
> must reconfigure the mail-server installation for their own system, network,
> and security model specifics by editing all necessary files and checking file
> permissions.
>
> Also, these settings are changes in mail-server’s post-activate block to use
> the current network settings of the installation. See:
> https://github.com/macports/macports-ports/blob/022f7da78c0cbab9492c60680569cf0483f2e48f/mail/mail-server/Portfile#L328-L342
>
> Bottom line: don’t waste time trying to coerce a Portfile to automatically
> configure your deployed mail server when there’s a zillion other settings
> you’ll have to take care of yourself anyway.
>
>> On Sep 20, 2019, at 11:37, Gerben Wierda wrote:
>>
>> The mail-server Portfile has this in it:
>>
>> # Network configuration
>> # hard-coded examples
>> set host host
>> set domain domain
>> set tld tld
>> set fullhost ${host}.${domain}.${tld}
>> set domaintld${domain}.${tld}
>> set HOST[string toupper ${host}]
>> set DOMAIN [string toupper ${domain}]
>> set TLD [string toupper ${tld}]
>> set FULLHOST [string toupper ${fullhost}]
>> set DOMAINTLD [string toupper ${domaintld}]
>> set relayhost mymailrelay.tld
>>
>> Now, obviously, my system isn’t called host.domain.tld or the relayhost
>> mymailrelay.tld.
>>
>> Is there a way I can influence these variables from the ‘outside’, so by
>> using envrionment variables or by providing them in some way with the 'port
>> install’ command?
>>
>> Gerben Wierda
>> Chess and the Art of Enterprise Architecture
>> Mastering ArchiMate
>> Architecture for Real Enterprises at InfoWorld
>> On Slippery Ice at EAPJ
>>
Re: Using outside values in a Portfile tcl
> > other strings such as ‘macportshost’ instead of ‘host’ would make it a lot
> > easier to find where they have been used so you know what to change
It’s already trivially easy to find, and only appears in four configuration
files anyway. As you can see in the Portfile, these variables are just used for
sed substitutions of strings like @HOST@ in the template files. Searching the
port files shows you exactly where these appear:
find
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/mail/mail-server/files/
-type f -exec fgrep -l @HOST@ {} ';' | wc -l
4
Again, I recommend focusing on the actual configuration of the deployed mail
server, not the MacPorts example configuration, unless you see something wrong
or insecure with the example configuration.
>> > obviously, my system isn’t called host.domain.tld or the relayhost
>> > mymailrelay.tld.
>>
>> Please refer to `port notes mail-server`:
>>
>> “Users must reconfigure this installation for their own system, network, and
>> security model specifics by editing all necessary files and checking file
>> permissions.”
Re: [MacPorts-announce] MacPorts 2.6.0 has been released
On Sep 20, 2019, at 22:30, Joshua Root wrote:
> Of special note for users of 10.6-10.8: The default C++ stdlib has
> changed from libstdc++ to libc++. This will enable building ports that
> require C++11 and beyond much more easily. All C++-based ports using the
> old stdlib will need to be rebuilt, so we recommend that you run 'sudo
> port rev-upgrade' after updating to MacPorts 2.6.0.
>
> We are currently in the process of switching the packages server over
> to the new stdlib, so availability of binary packages for 10.6-10.8 will
> be reduced for a time until the builds catch up. (There will initially
> be no availability for a hopefully very short time until we flip the
> switch to mark the archives as libc++.)
>
> If you previously followed the LibcxxOnOlderSystems instructions on the
> wiki, you should revert the changes to macports.conf that the
> instructions specify. In particular, default_compilers should not be set
> so that the new MacPorts version can pick the compilers itself. You also
> probably want buildfromsource to be its default value ("ifneeded") so
> that you will use binaries once they are available.
Users of Mac OS X 10.6-10.8 should definitely wait a few days before running
sudo port selfupdate or sudo port sync while we transition the build servers
over to the new C++ library.
Re: Portfile question (actually, tcl question)
Gerben Wierda writes:
> set startupitemstring [variant_isset "withdnsserver" ? "port load
> dns-server\n\t" : ""]
Try this one:
set startupitemstring [expr [variant_isset withdnsserver] ? {"port load
dns-server\n\t"} : {""}]
--
Piet van Oostrum
WWW: http://piet.vanoostrum.org/
PGP key: [8DAE142BE17999C4]
Thank you for defaulting to libc++ on older systems
I would like to thank everyone, especially Josh who did the bulk of the heavy lifting and Jeremy who initially designed the whole setup, for the work involved in making the default to libc++ happen for all these systems. Although, no doubt, we may find a few hiccups that need to be tweaked, on the whole I believe everyone's life will be easier. I appreciate the efforts involved, as do - I’m sure - many people. Although continuing support for these older systems can seem to be a burden at times, hopefully with this change, and with the legacysupport PG, we’ve made it as small a burden as possible. I continue to believe that MacPorts extremely robust support for older systems is one of our real strengths, and brings new users to MacPorts regularly. Thanks, Ken
