On 10/2/2014 4:55 PM, PGNd wrote: > On Thu, Oct 2, 2014, at 04:37 PM, Tom Eastep wrote: >>> Specifically, sandboxing multiple installs. "Everything" >>> installed under a selected $PREFIX. >> >> The install system is not designed to be able to have multiple >> runnable installations on a single system. You can have multiple >> inert installations by simply running install.sh as: >> >> DESTDIR=/dir/where/I/want/everything ./install.sh All paths set in >> shorewallrc are simply appended to $DESTDIR. > > I have to now recollect why I chose NOT to do that. There WAS a > 'very valid' reason a couple of eves ago ...
I am interested in your reason -- I would prefer to hack up that path
rather than risk breaking live installs.
>
> I'd rather that the ./install.sh, at least, had an option/flag to
> leave the decision about 'runable' to me -- letting the user
> enable/disable the services, in lieu of the script doing it.
Noted.
>
>> Don't specify both INITFILE and SYSTEMD. There is no need to
>> install the sysV init file if systemd is in use.
>
> The 'need' is to be able to *have* both sets of init-files as
> references in the target, install 'sandbox'. I do not expect to
> 'exec' them from there (I have chkconfing-/systemctl-containing
> scripts that manage the toggling outside of SW).
>
>> The SYSTEMD variable names the directory where *systemd* expects to
>> find its .service files.
>
> To me that's a very strange option to have. systemd on the OS
> defines the allowed/expected paths where it expects to find its
> .service files. I'm just trying to get the files installed somewhere
> in the sandbox that I can reference/copy them.
The install scripts are not clairvoyant. They use 'systemctl enable
$PRODUCT.service' to enable startup. That requires that the .service
file be installed in the correct place. Again, you could do that using
DESTDIR.
>
>> That won't work with Shorewall-init. If you set VARDIR to anything
>> but /VARLIB/$PRODUCT then Shorewall-init won't work.
>
> I suppose I, then,
>
> VARLIB=/var/lib/sw-custom VARDIR=${VARLIB}/$PRODUCT
>
> is allowed?
Yes.
I don't care which works, as long as I can segregate
>
>>> In any case, NOT having SW's install scripts
>>>
>>> (1) fail (2) install the wrong thing in the wrong place. (3) make
>>> automated presumptions (e.g. enabling a service) that can't be
>>> overridden
>>
>> Your two emails were identical except for the subject, so I only
>> know about the third issue.
>
> Agh, again. Copy-n-paste-itis. Sry. THIS email was SUPPOSED to have
> the FOLLOWING content (Now that I've royally screwed this up, I'll
> just paste it here, rather than tryting to edit/change titles.)
I'll respond to that separately.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
