Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

init script and installer #2

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

init script and installer #2

wants to merge 3 commits into from

Conversation

TrystanLea
Copy link

here's the init script and installer as discussed

@lafrech
Copy link

lafrech commented Nov 13, 2013

Hi.

Aside from apt-get, I don't know much about software installation, but I believe a common approach is to

./configure
make

as normal user

then

install

as root.

I imagine the rule here is to do the least operation as possible as root. This is not an absolute rule anyway.

The install script copies needed files into their destination directories. This is where I lack knowledge, and it may even depend on distributions, I don't know. I think it is /usr/local on Debian systems.

I did the checkout and the make as normal user. Now if I install as root, I'm allowing the automatic startup of a file owned by a normal user (myself). Not good. Moreover, if I now make as root, the file is not modified and still belongs to my normal user. If I make clean then make as root, the file belongs to root, which is safe.

If the steps proposed by Trystan here are followed strictly

cd /home/username
git clone https://github.com/TrystanLea/timestore
cd timestore
sudo sh install

then there is no direct security issue. But if I'm a curious user and want to do the git and compilation steps as user before doing anything, I'm endangering my system when executing the install script.

It may be a cleaner approach to do the installation as a copy in /usr/local, but again I let you judge, I'm no guru. Just wanted to bring your attention on this. Please forgive me if this is misplaced.

@lafrech
Copy link

lafrech commented Nov 14, 2013

It may be worse than I thought. When executing make as root, the extraction of the microhttpd archive is executed as root.

By default, when extracting with any user, the ownership of extracted files belongs to the user. Apparently, with root user, as an exception, the ownership is preserved.

See man tar:

     --same-owner
           try extracting files with the same ownership as exists in the archive (default for superuser)

     --no-same-owner
           extract files as yourself (default for ordinary users)

My understanding is that when doing make and install as root, extracted microhttpd files are owned by user and group whose UID and GID correspond to the owner (or perhaps the creator of the archive, I don't know) on the system where the tar was made. This can be any random user/group on the local machine.

The -no-same-owner flag could be used, but I think the clean way would be to make as user, then copy as root to a more appropriate location. I think this location is /usr/local. See here, for instance.

My suggestion is to

  • identify which files are needed for execution
  • in the install script, copy those files as root to /usr/local/timestore, or perhaps separate /use/local/timestore and /usr/local/libmicrohttpd

(I didn't check what libmicrohttp is and what it is used for.)

@mikestir
Copy link
Owner

Hi Jerome. I've already added autotools support (make/make install) in the upstream branch, but Trystan hasn't merged it yet. The plan was to build some .deb packages but I haven't had time so far.

The autotools build removes the bundled libmicrohttpd altogether because most recent distributions should have a new enough version in their repositories, so you can just apt-get install it.

Mike

@lafrech
Copy link

lafrech commented Nov 15, 2013

Great.I didn't see that.

Indeed, I have libmicrohttpd10 version 0.9.20 available.

I'll have a look at your install script.

Thanks.

@lafrech
Copy link

lafrech commented Nov 28, 2013

Hi.

I tried to install using the new install procedure and I don't get it working.

On a fresh Wheezy, I installed packages libmicrohttpd1, autotools-dev, automake and autoconf. Not sure all of these are required.

Now, I don't know what to do. Are README and INSTALL files accurate ?

make: *** No targets specified and no makefile found.  Stop.
./configure.ac: line 1: syntax error near unexpected token `[2.65]'
./configure.ac: line 1: `AC_PREREQ([2.65])'

I tried autoreconf and now I got a configure file

./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether gcc and cc understand -c and -o together... yes
checking for sinf in -lm... yes
./configure: line 3505: syntax error near unexpected token `libmicrohttpd,'
./configure: line 3505: `PKG_CHECK_MODULES(libmicrohttpd, libmicrohttpd)'

Anything I'm doing wrong ? Or is it known not to work ?

@ferdinandkeil
Copy link

@jerome-github I got the same message but was able to get it working after installing pkg-config. I'm doing

autoreconf -i
./configure
make all
checkinstall

However you'll still have to setup the user timestore and create the directory /var/lib/timestore:

mkdir /var/lib/timestore
adduser timestore
chown timestore /var/lib/timestore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants