[lxc-devel] [PATCH] lxc-busybox: check when bind-mounting host libdirs
The patch changes the busybox template behavior to automatically mount /lib and /usr/lib. In case one of these folders does not exist, starting the container will fail. Also, if there are other lib entries on the host - e.g. /usr/lib64 - mount them as well. Signed-off-by: Bogdan Purcareata --- templates/lxc-busybox.in | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/templates/lxc-busybox.in b/templates/lxc-busybox.in index cb425ec..49effae 100644 --- a/templates/lxc-busybox.in +++ b/templates/lxc-busybox.in @@ -240,13 +240,6 @@ lxc.pts = 1 #lxc.aa_profile = unconfined EOF -if [ -d "$rootfs/lib" ]; then -cat <> $path/config -lxc.mount.entry = /lib $rootfs/lib none ro,bind 0 0 -lxc.mount.entry = /usr/lib $rootfs/usr/lib none ro,bind 0 0 -EOF -fi - libdirs="\ lib \ usr/lib \ @@ -255,6 +248,7 @@ fi for dir in $libdirs; do if [ -d "/$dir" ] && [ -d "$rootfs/$dir" ]; then +echo "lxc.mount.entry = /$dir $rootfs/$dir none ro,bind 0 0" >> $path/config echo "lxc.mount.entry = /$dir $dir none ro,bind 0 0" >> $path/config fi done -- 1.7.11.7 -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Cleanup of .hold files
Quoting Brent Tubbs (brent.tu...@yougov.com): > Hi, > > I see in conf.c that a .hold file is automatically created whenever > you use a directory as the rootfs. I'm seeing those start to > accumulate on the filesystem. Is it my job to clean them up, or > should there be code in LXC deleting them when the container shuts > down? Would be nice for lxc to remove them. I'm not 100% sure, but I suspect if we unlink the file right after opening it in src/lxc/conf.c:pin_rootfs(), that should still suffice to prevent unmounting the filesystem. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/4] coverity: don't reference beyond structure
On Fri, 3 May 2013 13:47:59 -0400
Dwight Engen wrote:
> On Fri, 3 May 2013 12:23:29 -0500
> Serge Hallyn wrote:
>
> > Quoting Dwight Engen (dwight.en...@oracle.com):
> > > On Fri, 3 May 2013 11:17:08 -0500
> > > Serge Hallyn wrote:
> > >
> > > > can that be correct? That changes the value of the
> > > > pointer. NLMSG_DATA adds aligned sizeof(struct nlmsghdr).
> > >
> > > The current code is relying on the fact that our genlmsg looks
> > > like this:
> > >
> > > struct genlmsg {
> > > struct nlmsghdr nlmsghdr;
> > > struct genlmsghdr genlmsghdr;
> > > };
> > >
> > > so NLMSG_DATA(&request->nlmsghdr) == genlmsghdr (I think sizeof
> > > struct nlmsghdr will make genlmsghdr be aligned anyway?). Right
> > > now lxc doesn't use this code so I cannot test it in lxc, but let
> > > me write a test program that dumps the pointers using the old way
> > > and the new way. We do have a 2*PAGE_SIZE buffer these point to
> > > so I'm sure its not overflowing, so maybe we do just want to
> > > ignore coverity.
> >
> > Thanks, I'll go ahead and apply the rest and hold off on this one.
>
> Yeah I agree we should hold off. The following test program shows them
> equivalent, but using NLMSG_DATA may be more appropriate. The
> commented out __attribute__ ((aligned(4))); in genl.h make me
> suspicous this has come up before. Maybe I can look into a way to
> make coverity happy instead.
Just to follow up, I did check what libnl does, and it has nlmsg_data()
that just adds NLMSG_HDRLEN to a nlmsghdr pointer. This is equivalent
to of our use of NLMSG_DATA so I think we should just leave the code as
is and not apply this patch.
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/4] coverity: don't reference beyond structure
Quoting Dwight Engen (dwight.en...@oracle.com):
> On Fri, 3 May 2013 13:47:59 -0400
> Dwight Engen wrote:
>
> > On Fri, 3 May 2013 12:23:29 -0500
> > Serge Hallyn wrote:
> >
> > > Quoting Dwight Engen (dwight.en...@oracle.com):
> > > > On Fri, 3 May 2013 11:17:08 -0500
> > > > Serge Hallyn wrote:
> > > >
> > > > > can that be correct? That changes the value of the
> > > > > pointer. NLMSG_DATA adds aligned sizeof(struct nlmsghdr).
> > > >
> > > > The current code is relying on the fact that our genlmsg looks
> > > > like this:
> > > >
> > > > struct genlmsg {
> > > > struct nlmsghdr nlmsghdr;
> > > > struct genlmsghdr genlmsghdr;
> > > > };
> > > >
> > > > so NLMSG_DATA(&request->nlmsghdr) == genlmsghdr (I think sizeof
> > > > struct nlmsghdr will make genlmsghdr be aligned anyway?). Right
> > > > now lxc doesn't use this code so I cannot test it in lxc, but let
> > > > me write a test program that dumps the pointers using the old way
> > > > and the new way. We do have a 2*PAGE_SIZE buffer these point to
> > > > so I'm sure its not overflowing, so maybe we do just want to
> > > > ignore coverity.
> > >
> > > Thanks, I'll go ahead and apply the rest and hold off on this one.
> >
> > Yeah I agree we should hold off. The following test program shows them
> > equivalent, but using NLMSG_DATA may be more appropriate. The
> > commented out __attribute__ ((aligned(4))); in genl.h make me
> > suspicous this has come up before. Maybe I can look into a way to
> > make coverity happy instead.
>
> Just to follow up, I did check what libnl does, and it has nlmsg_data()
> that just adds NLMSG_HDRLEN to a nlmsghdr pointer. This is equivalent
> to of our use of NLMSG_DATA so I think we should just leave the code as
> is and not apply this patch.
Thanks, Dwight.
-serge
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] lxc-busybox: check when bind-mounting host libdirs
Quoting Bogdan Purcareata (bogdan.purcare...@freescale.com): > The patch changes the busybox template behavior to automatically > mount /lib and /usr/lib. In case one of these folders does not exist, > starting the container will fail. Also, if there are other lib entries > on the host - e.g. /usr/lib64 - mount them as well. > > Signed-off-by: Bogdan Purcareata Thanks. You're right the first part should be dropped. However there's no need that I can see for the line you add. The two lxc.mount.entry = /$dir $dir none ro,bind 0 0 and lxc.mount.entry = /$dir $rootfs/$dir none ro,bind 0 0 mean the same thing, with the first being preferred as it will work if you (while high on $drug) decide to back it with a block device :) Do you mind resending without that line (assuming you agree)? I'll then ack and push. > --- > templates/lxc-busybox.in | 8 +--- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/templates/lxc-busybox.in b/templates/lxc-busybox.in > index cb425ec..49effae 100644 > --- a/templates/lxc-busybox.in > +++ b/templates/lxc-busybox.in > @@ -240,13 +240,6 @@ lxc.pts = 1 > #lxc.aa_profile = unconfined > EOF > > -if [ -d "$rootfs/lib" ]; then > -cat <> $path/config > -lxc.mount.entry = /lib $rootfs/lib none ro,bind 0 0 > -lxc.mount.entry = /usr/lib $rootfs/usr/lib none ro,bind 0 0 > -EOF > -fi > - > libdirs="\ > lib \ > usr/lib \ > @@ -255,6 +248,7 @@ fi > > for dir in $libdirs; do > if [ -d "/$dir" ] && [ -d "$rootfs/$dir" ]; then > +echo "lxc.mount.entry = /$dir $rootfs/$dir none ro,bind 0 0" >> > $path/config > echo "lxc.mount.entry = /$dir $dir none ro,bind 0 0" >> > $path/config > fi > done > -- > 1.7.11.7 > > > > -- > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > ___ > Lxc-devel mailing list > Lxc-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [RFC PATCH 0/1] allow setting cgroup items before the cgroup is entered
Quoting Dwight Engen (dwight.en...@oracle.com): > Hi, > > I tried to put lxc.cgroup.memory.kmem.limit_in_bytes = 4194304 in a > config file to test forkbomb prevention. The problem with this is that > kmem.limit_in_bytes (per the kernel documentation) "cannot be set if > the cgroup have children, or if there are already tasks in the cgroup". > Currently, lxc does lxc_cgroup_enter() before doing setup_cgroup() in > the lxc_spawn() flow and therefore gets -EBUSY. > > Commit 544a48a0 leads me to believe that we don't want to move > setup_cgroup() earlier, so I've refactored it to create an additional > setup_cgroup_pre_enter() that gets called before lxc_cgroup_enter(). > Currently it only writes kmem.limit_in_bytes, if there are other items > that need to be setup pre-enter, they could easily be added to the > list. This fixes the problem for me. I think we are trying to keep lxc > from knowing about specific cgroup control knobs, but I have not > thought of another way to do this. Thoughts? I think the only problem with configuring cgroups early is that some block devices which the container might want to mount could be denied. So perhaps we should do the inverse of what you're doing. Configure all cgroups right before lxc_cgroup_enter(), except for devices cgroup, which gets configured after mounts happen? -serge -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] lxc-alpine: download statically compiled package manager if not available on host
Signed-off-by: Kaarle Ritvanen
---
templates/lxc-alpine.in | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/templates/lxc-alpine.in b/templates/lxc-alpine.in
index 98347ed..528ebca 100644
--- a/templates/lxc-alpine.in
+++ b/templates/lxc-alpine.in
@@ -1,6 +1,9 @@
#!/bin/sh
install_alpine() {
+apk=${APK:-apk}
+apk_opts=
+
rootfs="$1"
shift
mkdir -p "$rootfs"/etc/apk || return 1
@@ -10,11 +13,32 @@ install_alpine() {
else
cp /etc/apk/repositories "$rootfs"/etc/apk/repositories || return 1
fi
-opt_arch=
+
if [ -n "$apk_arch" ]; then
-opt_arch="--arch $apk_arch"
+apk_opts="--arch $apk_arch"
fi
-${APK:-apk} add -U --initdb --root $rootfs $opt_arch "$@" alpine-base
+
+if ! which $apk &> /dev/null; then
+wget="wget -O - $repository/x86"
+
+apk_version=$($wget/APKINDEX.tar.gz | \
+tar -Oxz APKINDEX | \
+sed 's/^$//;Ta;x;
+ s/^\(.*\n\)P:apk-tools-static\(\n.*\)$/\1\2/;Tb;
+ s/^\(.*\n\)V:\([^\n]\+\)\(\n.*\)$/\2/;t;
+ :a;H;:b;d')
+[ "$apk_version" ] || return 1
+
+apk=$(mktemp /tmp/apk.static.XX)
+trap "rm -f $apk" EXIT
+$wget/apk-tools-static-$apk_version.apk | \
+tar -Oxz sbin/apk.static > $apk || return 1
+chmod u+x $apk
+
+apk_opts="$apk_opts --allow-untrusted"
+fi
+
+$apk add -U --initdb --root $rootfs $apk_opts "$@" alpine-base
}
configure_alpine() {
--
1.8.1.4
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] create api
Hi, I'd like to rewrite lxc-create to be c (calling out to the c templates which continue to be scripts for the most part). Unfortunately right now the lxcapi_create() just takes arguments to send to the lxc-create script. I could either dump the existing lxcapi_create function, replace it with something close to the lxcapi_clone, and update the current callers, or I can write a new function lxcapi_create2, keeping lxcapi_create() as calling the c program (which then calls lxcapi_create2 :). The only reason to go with lxcapi_create2 would be for out of tree callers (which includes the go bindings). Since we're not at 1.0 yet we don't guarantee anything about api stability (for exactly this reason), but I thought I'd ask anyway what you all thought. -serge -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] create api
On Tue, 14 May 2013 14:13:45 -0500 Serge Hallyn wrote: > Hi, > > I'd like to rewrite lxc-create to be c (calling out to the c templates > which continue to be scripts for the most part). Unfortunately right > now the lxcapi_create() just takes arguments to send to the lxc-create > script. > > I could either dump the existing lxcapi_create function, replace it > with something close to the lxcapi_clone, and update the current > callers, or I can write a new function lxcapi_create2, keeping > lxcapi_create() as calling the c program (which then calls > lxcapi_create2 :). > > The only reason to go with lxcapi_create2 would be for out of tree > callers (which includes the go bindings). Since we're not at 1.0 yet > we don't guarantee anything about api stability (for exactly this > reason), but I thought I'd ask anyway what you all thought. I'd vote for trying to keep the API as clean as possible until 1.0, but then I don't have an out of tree caller to update. This brings up a question though, with 1.0 we are going to consider stable the lxcapi_* routines only and not all symbols available from liblxc.so, correct? > -serge -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] create api
On 05/14/2013 05:28 PM, Dwight Engen wrote: > On Tue, 14 May 2013 14:13:45 -0500 > Serge Hallyn wrote: > >> Hi, >> >> I'd like to rewrite lxc-create to be c (calling out to the c templates >> which continue to be scripts for the most part). Unfortunately right >> now the lxcapi_create() just takes arguments to send to the lxc-create >> script. >> >> I could either dump the existing lxcapi_create function, replace it >> with something close to the lxcapi_clone, and update the current >> callers, or I can write a new function lxcapi_create2, keeping >> lxcapi_create() as calling the c program (which then calls >> lxcapi_create2 :). >> >> The only reason to go with lxcapi_create2 would be for out of tree >> callers (which includes the go bindings). Since we're not at 1.0 yet >> we don't guarantee anything about api stability (for exactly this >> reason), but I thought I'd ask anyway what you all thought. > > I'd vote for trying to keep the API as clean as possible until 1.0, but > then I don't have an out of tree caller to update. This brings up a > question though, with 1.0 we are going to consider stable the > lxcapi_* routines only and not all symbols available from liblxc.so, > correct? Correct, at least that was my plan. >> -serge > -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: OpenPGP digital signature -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] lxc-fedora-template: autodev, hostname, ARM archs, Raspberry Pi fixes
This took a lot longer for me to get around to it... Sorry.
Patch to the lxc-fedora template.
I didn't get any further comments from my earlier proposal, weeks ago,
and did get one addition based on comments about properly setting the
hostname in /etc/hostname, which I've added. I could have broken them
into separate patches but most are pretty small and minor.
Changes:
* Map armv6l and armv7l architectures to "arm" for yum and repos to
function properly.
* Detect Fedora Remix distros with no "/etc/fedora-release" file
(Raspberry Pi) and find proper release versions when "remix" part of the
file context.
* Change default Fedora container on non-Fedora hosts to Fedora 17.
* Added code for autodev for Fedora systemd containers.
* Added code to set /etc/hostname for Fedora > 14 (systemd).
* Fix a few typos.
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it!
--
Signed-off-by: Michael H. Warfield
---
diff --git a/templates/lxc-fedora.in b/templates/lxc-fedora.in
index 684bb9c..a828dff 100644
--- a/templates/lxc-fedora.in
+++ b/templates/lxc-fedora.in
@@ -32,12 +32,28 @@ default_path=@LXCPATH@
root_password=root
# is this fedora?
-[ -f /etc/fedora-release ] && is_fedora=true
-
-if [ "$arch" = "i686" ]; then
-arch=i386
+# Alow for weird remixes like the Raspberry Pi
+if [ -e /etc/redhat-release ]
+then
+fedora_host_ver=$( sed -e '/^Fedora /!d' -e
's/Fedora.*\srelease\s*\([0-9][0-9]*\)\s.*/\1/' < /etc/redhat-release )
+if [ "$fedora_host_ver" != "" ]
+then
+is_fedora=true
+fi
fi
+# Map a few architectures to their generic Fedora repository archs.
+# The two ARM archs are a bit of a guesstimate for the v5 and v6
+# archs. V6 should have hardware floating point (Rasberry Pi).
+# The "arm" arch is safer (no hardware floating point). So
+# there may be cases where we "get it wrong" for some v6 other
+# than RPi.
+case "$arch" in
+i686) arch=i386 ;;
+armv3l|armv4l|armv5l) arch=arm ;;
+armv6l|armv7l|armv8l) arch=armhfp ;;
+esac
+
configure_fedora()
{
@@ -62,9 +78,15 @@ NETWORKING=yes
HOSTNAME=${name}
EOF
+# set hostname on systemd Fedora systems
+if [ $release -gt 14 ]; then
+echo "${name}" > ${rootfs_path}/etc/hostname
+fi
+
# set minimal hosts
cat < $rootfs_path/etc/hosts
127.0.0.1 localhost $name
+::1 localhost6.localdomain6 localhost6
EOF
dev_path="${rootfs_path}/dev"
@@ -253,6 +275,8 @@ lxc.tty = 4
lxc.pts = 1024
lxc.mount = $config_path/fstab
+lxc.autodev = $auto_dev
+
# When using LXC with apparmor, uncomment the next line to run unconfined:
#lxc.aa_profile = unconfined
@@ -320,7 +344,7 @@ Mandatory args:
Optional args:
-p,--path path to where the container rootfs will be created,
defaults to @LXCPATH@. The container config will go under @LXCPATH@ in that case
-c,--cleanclean the cache
- -R,--release Fedora release for the new container. if the host is
Fedora, then it will defaultto the host's release.
+ -R,--release Fedora release for the new container. if the host is
Fedora, then it will default to the host's release.
-A,--arch NOT USED YET. Define what arch the container will be
[i686,x86_64]
-h,--help print this help
EOF
@@ -365,7 +389,7 @@ fi
if [ -n "$needed_pkgs" ]; then
echo "Missing commands: $needed_pkgs"
-echo "Please install these using \"sudo apt-get install $needed_pkgs\""
+echo "Please install these using \"sudo yum install $needed_pkgs\""
exit 1
fi
@@ -374,14 +398,22 @@ if [ -z "$path" ]; then
fi
if [ -z "$release" ]; then
-if [ "$is_fedora" ]; then
-release=$(cat /etc/fedora-release |awk '/^Fedora/ {print $3}')
+if [ "$is_fedora" -a "$fedora_host_ver" ]; then
+release=$fedora_host_ver
else
-echo "This is not a fedora host and release missing, defaulting to 14.
use -R|--release to specify release"
-release=14
+echo "This is not a fedora host and release missing, defaulting to 17.
use -R|--release to specify release"
+release=17
fi
fi
+# Fedora 15 and above run systemd. We need autodev enabled to keep
+# systemd from causing problems.
+if [ $release -gt 14 ]; then
+auto_dev="1"
+else
+auto_dev="0"
+fi
+
if [ "$(id -u)" != "0" ]; then
echo "This script should be run as 'root'"
exit 1
signature.asc
Description: This is a digitally signed message part
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security contr
Re: [lxc-devel] [PATCH] lxc-alpine: download statically compiled package manager if not available on host
On Tue, 14 May 2013 19:27:32 +0300
Kaarle Ritvanen wrote:
> Signed-off-by: Kaarle Ritvanen
I have looked over it and tested it on Alpine Linux.
It should make it very simple to test an Alpine Linux container on any
x86/x86_64 GNU Linux.
Acked-by: Natanael Copa
> ---
> templates/lxc-alpine.in | 30 +++---
> 1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/templates/lxc-alpine.in b/templates/lxc-alpine.in
> index 98347ed..528ebca 100644
> --- a/templates/lxc-alpine.in
> +++ b/templates/lxc-alpine.in
> @@ -1,6 +1,9 @@
> #!/bin/sh
>
> install_alpine() {
> +apk=${APK:-apk}
> +apk_opts=
> +
> rootfs="$1"
> shift
> mkdir -p "$rootfs"/etc/apk || return 1
> @@ -10,11 +13,32 @@ install_alpine() {
> else
> cp /etc/apk/repositories "$rootfs"/etc/apk/repositories || return 1
> fi
> -opt_arch=
> +
> if [ -n "$apk_arch" ]; then
> -opt_arch="--arch $apk_arch"
> +apk_opts="--arch $apk_arch"
> fi
> -${APK:-apk} add -U --initdb --root $rootfs $opt_arch "$@" alpine-base
> +
> +if ! which $apk &> /dev/null; then
> +wget="wget -O - $repository/x86"
> +
> +apk_version=$($wget/APKINDEX.tar.gz | \
> +tar -Oxz APKINDEX | \
> +sed 's/^$//;Ta;x;
> + s/^\(.*\n\)P:apk-tools-static\(\n.*\)$/\1\2/;Tb;
> + s/^\(.*\n\)V:\([^\n]\+\)\(\n.*\)$/\2/;t;
> + :a;H;:b;d')
> +[ "$apk_version" ] || return 1
> +
> +apk=$(mktemp /tmp/apk.static.XX)
> +trap "rm -f $apk" EXIT
> +$wget/apk-tools-static-$apk_version.apk | \
> +tar -Oxz sbin/apk.static > $apk || return 1
> +chmod u+x $apk
> +
> +apk_opts="$apk_opts --allow-untrusted"
> +fi
> +
> +$apk add -U --initdb --root $rootfs $apk_opts "$@" alpine-base
> }
>
> configure_alpine() {
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
