guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#60735] [PATCH v2 2/3] system: Deprecate hosts-file.


From: Bruno Victal
Subject: [bug#60735] [PATCH v2 2/3] system: Deprecate hosts-file.
Date: Mon, 23 Jan 2023 23:19:00 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1

On 2023-01-23 22:37, Ludovic Courtès wrote:
> Bruno Victal <mirai@makinata.eu> skribis:
> 
>> ---
>>
>> WIP, the ganeti tests fail because host-name is added as an alias of 
>> localhost.
> 
> Before these patches, ‘host-name’ was already an alias of ‘localhost’.
> Is there something else interfering?

In some cases, it's not desired for host-name to be an alias of localhost.
The ganeti tests did this by passing a hosts-file file-like object where
host-name wasn't an alias of localhost.

I've brainstormed a bit on this and here's what I thought:

Approach 1 (DOESN'T WORK):
* hosts-service-type in essential-services (gnu/systems.scm), default value:
        127.0.0.1  localhost
        ::1  localhost
* simple-service extension on base-services (gnu/services/base.scm):
        \\FLOPS since both /etc/hosts and /etc/hostname are provisioned with 
activation-service-type.
        This means we can't write /etc/hosts AFTER /etc/hostname or 
host-name-service-type is ready.

Approach 2:
* NO /etc/hosts in essential-services (is this possible?)
        * is an absent /etc/hosts (or absent %base-services) a valid OS?
* Value set in %base-services, hosts-service-type as a ONE-SHOT shepherd 
service.
        * Can be changed with modify-services.
        * It's a one-shot shepherd service since we're depending on 
/etc/hostname which is activation-service-type. (we're depending on either 
etc-service-type or host-name-service-type)

Approach 3:
* Do not set our hostname as an alias of localhost by default.
        * Manpage doesn't seem to make this mandatory, in fact, our hostname 
can point to any IP. (it says 'often', not 'mandatory')
        * We only set localhost name.
                * Is this mandatory? If not, there might be cases where this 
entry is undesired.

> 
>> +    (simple-service 'block-facebook-hosts hosts-service-type
>> +                    (let ((host-pairs
>> +                            (filter-map
>> +                              (lambda (x)
>> +                                (and (not (or (string-null? x)
>> +                                              (string-prefix? "#" x)))
>> +                                 (remove string-null?
>> +                                             (string-split
>> +                                               x
>> +                                               char-set:whitespace))))
>> +                              (string-split %facebook-host-aliases 
>> #\newline))))
>> +                      (map (match-lambda
>> +                             ((addr name)
>> +                              (host addr name)))
>> +                           host-pairs)))
> 
> It doesn’t matter because it’s removed in the commit that follows I
> think using ‘string-tokenize’ instead of ‘string-split’ may bring
> simplifications.

It was added because otherwise the "split" commits would seem to be missing 
some context.
I can leave it as is, delete it here or try your suggestion.

>> +++ b/gnu/system.scm
>> @@ -14,6 +14,7 @@
>>  ;;; Copyright © 2020, 2022 Efraim Flashner <efraim@flashner.co.il>
>>  ;;; Copyright © 2021 Maxime Devos <maximedevos@telenet.be>
>>  ;;; Copyright © 2021 raid5atemyhomework <raid5atemyhomework@protonmail.com>
>> +;;; Copyright © 2023 Bruno Victal <mirai@makinata.eu>
>>  ;;;
>>  ;;; This file is part of GNU Guix.
>>  ;;;
>> @@ -31,6 +32,7 @@
>>  ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
>>  
>>  (define-module (gnu system)
>> +  #:use-module (guix discovery)
> 
> Do we really need this module?

IIRC this was for the deprecated procedures to work. Can they work without this 
module?


Cheers,
Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]