Systemd script

Reindl Harald h.reindl at thelounge.net
Fri Feb 19 13:22:50 UTC 2016



Am 19.02.2016 um 14:15 schrieb Josep Manel Andrés:
> You are right, I think I will give it a try. So I guess that I will have
> to prepare two packages (at least) if I wanna run it on a chroot env.
>
> bind and bind-chrootenv packages.
>
> And I think I should get the specs files from the 9.9.6P1 available on
> the SLES12 Repos.

one package should be enough, for your own usage you may decide if you 
want chroot or not and use named on all machines the same way, since you 
install that one parallel a bind-libs package of the distribution you 
can even "rm" some binaries like dig and so on in the buildprocess as 
well as the docs and readmes

one big benefit of a own RPM - my mariadb SPEC has more rm-lines than 
anything else :-)

> On 19/02/16 12:56, Reindl Harald wrote:
>>
>>
>> Am 19.02.2016 um 12:46 schrieb Josep Manel Andrés:
>>> I am not too confident to build RPM packages, that is why I wanted to go
>>> for a normal installation from source.
>>
>> well, learn it, it's really not hard to do
>>
>> i learnt it the hard way that "make install" over years leaves more and
>> more mess while a rpm package automatically removes obsolete files and
>> the build process finally makes sure that it aborts if anything in the
>> %files section did not exist after compile or a new file is not listed
>> in %files due a upgrade
>>
>> you will notice that when you did a major upgrade which don't work and
>> have no simple downgrade way
>> _____________________________________
>>
>> additionally normally on a production server you should not install
>> compilers and devel-packages and on the other hand on the build machine
>> install the service with a test config - so you can make sure it will
>> work on the procution machine or find out what needs to be chnaged
>> *before* your service fails
>>
>> you know if your systemd-unit works as expected before it touchs your
>> server by proper testing and the resulting package pulls all
>> dependencies on the target machine (at least on Fedora they are
>> automatically added)
>> _____________________________________
>>
>> security: if something goes wrong in the build or with "make install" on
>> the production machine you have no way to roll back, "make install" with
>> rpmbuild runs as tesricted user and can't overwrite any files by accident
>>
>> in short: "make && make install" on production servers is a nogo
>>
>>> On 19/02/16 12:28, Reindl Harald wrote:
>>>>
>>>>
>>>> Am 19.02.2016 um 12:25 schrieb Reindl Harald:
>>>>> Am 19.02.2016 um 12:13 schrieb Josep Manel Andrés:
>>>>>> Hi Harald,
>>>>>> Thanks, but I suspect those are the files that come with the default
>>>>>> system installation, but not usable (without modifications) if I have
>>>>>> compiled it from source. Am I right?
>>>>>
>>>>> well, it should not be that hard to adopt them for your needs or even
>>>>> build a proper package containing all that stuff - only over my dead
>>>>> body i would do a "make install" on any machine oustide rpmbuild
>>>>
>>>> BTW - why don't you just take the SuSE src.rpm, modify the SPEC file
>>>> for
>>>> the location where you want to have your own build installed and fire
>>>> some sed-commands in the buildprocess to scripts and config files?
>>>>
>>>> that way you only need to swap the tarball, change the version
>>>> number in
>>>> the SPEC and have proper updates in the future

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160219/11b4b8f7/attachment.bin>


More information about the bind-users mailing list