While creating RPMs, the RPM spec files have a directive %defattr . I know that it defines the default attributes for the files that are installed by that RPM. If I write the %defattr as below, what does it mean?
%defattr(-testuser, testuser)
The mode you specified is invalid. %defattr takes four arguments
From http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-FLIST-DEFATTR-DIRECTIVE
The %defattr Directive
The %defattr directive allows setting of default attributes for files and directives. The %defattr has a similar format to the %attr directive:
The default permissions, or "mode" for files.
The default user id.
The default group id.
The default permissions, or "mode" for directories.
The %attr directive has the following format:
%defattr(file mode, user, group, dir mode)
As with %attr if a particular attribute does not need to
be specified (usually because the file is installed with that
attribute set properly), then that attribute may be replaced with a
dash. In addition the directory mode may be ommited. %defattr tends to
be used at the top of %files.
To set permissions and ownerships in a spec file treat the directory like a file thusly...
%defattr will set all files without %attr (in this case rww owner apache group apache and set directories to 755).
%files
#%attr(<mode>, <user>, <group>) file
%defattr(644,apache,apache,755)
%attr(-,apache,apache) /var/www/coolapp
%attr(-,apache,apache) /var/www/coolapp/js
%attr(-,apache,apache) /var/www/coolapp/static
/var/www/coolapp/index.html
/var/www/coolapp/__init__.py
/var/www/coolapp/settings.py
/var/www/coolapp/urls.py
/var/www/coolapp/wsgi.py
Related
By default, the logging directory in Shopware6 is var/log.
How can I change it to something different like /var/log/shopware6 without creating a symlink?
That directory is a Symfony default. You can change it by setting an environment variable APP_LOG_DIR with an absolute path to a writable directory e.g. in you .env file.
In all configuration below, a prefix of "solr." for class names
is an alias that causes solr to search appropriate packages,
including org.apache.solr.(search|update|request|core|analysis)
You may also specify a fully qualified Java classname if you
have your own custom plugins.
This is what I found while going through the solrconfig.xml file. But it seems this is defined to point to the respective classes in solr. I know somehow SOLR_HOME is used for solr.data.dir. I have used solr using "start.jar" and also using "solr-**-*.war" on Tomcat. It just works !!! :)
So where does solr.data.dir points to ?
Where exactly is SOLR_HOME is defined ?
So where does solr.data.dir points to?
The dataDir parameter is used to specify the directory for storing all index data. If this directory is not absolute, then it is relative to the directory where you started Solr. If the folder is empty, the new index would be re-created automatically when starting Solr.
Where exactly is SOLR_HOME is defined?
It really depends on operating system and web server used. And it defines the home directory of your Solr.
The most commonly it could be defined either:
in startup files,
using system environment variables, e.g.:
export JAVA_OPTS="$JAVA_OPTS -Dsolr.solr.home=/opt/solr/example"
during runtime as part of JAVA_OPTS (on Debian, in /etc/default/tomcat7 for instance, format: -Dmy.prop=value),
using System property substitution file (core.properties/solrcore.properties),
using Tomcat Context Configuration (e.g. in conf/Catalina/localhost by solr/home),
per Solr instance in solr.xml (instanceDir).
Best is to specify it explicitly.
You can modify tomcat/bin/catalina.sh to add following JVM option:
-Dsolr.solr.home=/home/mdhussain/solr-test/deployment/solr1
Data directory is relative to solr home, you can override this in solrconfig.xml.
If you are running on a MAC it's default installation directory (including data)
- if installed via maven dependency at least - is in the /var/XXX directory.
cd /var
grep --color -iHrn solr .
Example on my machine for the index data location:
/var/folders/1j/z7f1373977s_qlfvv9t71kmh0000gq/T/solr-7.3.1/solr-7.3.1/server/solr/cores/catalog_reindex/data
According to Apache manual, the Include directive is recursive when a directory path is used. But is it recursive when using a wildcard path?
Include "/usr/local/apache/conf/userdata/std/2/username/domain.com/*.conf"
I checked it and it is not recursive.
As Joyce already said, I can confirm by testing it myself that it is not recursive.
Include uses fnmatch as wildcard engine, which doesn't match a slash by default, unless the FNM_PATHNAME flag is set, so a * doesn't match / so domain.com/*.conf will not look in sub-directories.
However, since httpd 2.3.6 it is possible to also use the wildcard for sub-directories.
Examples
Include /usr/local/apache2/conf.d/ssl.conf
This matches only a specific file.
Include /usr/local/apache2/conf.d
If conf.d is a file, it matches only this file. If conf.d is a directory, all files will be matched recursively, including files in sub-directories and non-conf files (which causes an error).
Include /usr/local/apache2/conf.d/*.conf
This will only match the files with a .conf suffix, directly located in the conf.d directory. Files in sub-directories aren't matches.
Include /usr/local/apache2/conf.d/*/*.conf
This will only match the files with a .conf suffix, directly located in sub-directories of the conf.d directory, but it will NOT match files directly located in the conf.d directory.
So for example, if you need to match all .conf files directly located in conf.d and in first level of sub-directories and second level of sub-directories, you can use this:
Include /usr/local/apache2/conf.d/*.conf
Include /usr/local/apache2/conf.d/*/*.conf
Include /usr/local/apache2/conf.d/*/*/*.conf
If you only have valid configuration files in conf.d and want to match every level of subdirectories, then you can use:
Include /usr/local/apache2/conf.d
Instead of using wildcard, you should use a directory.
It has been supported since as early as 1.3 https://httpd.apache.org/docs/1.3/mod/core.html#include
New in Apache 1.3.13 is the feature that if Include points to a directory, rather than a file, Apache will read all files in that directory, and any subdirectory, and parse those as configuration files.
I can't rely on the umask since my machine does not use umask to set permissions. Is there a way to specify that all sub-directories (and their sub-directories etc) of some root directory all have a certain permission, and similarly, that all sub-files of the same root directory have another type of permission in the %files section of the spec file.
If not, I'll have to run some external bash scrip to get the spec file syntax for each individual file, and copy that output to the %files section of the spec file, which will be highly tedious.
If you look at the various references online, %defattr() takes a lesser-known fourth parameter for directories.
I've tried 'umask 77' in the shell, then building it with:
[non-root-user#machine SPECS]$ rpmbuild -bb SPECFILE.spec
but I still get this from the output:
+ umask 022
You cannot change the umask from the shell because rpmbuild will always set a a fixed umask of 0022 before running %prep script.
Therefore, depending on what you're trying to achieve, you could try change the umask in the spec file, at the beginning the %prep section:
%prep
umask 077
But, if you're just trying to set the file permissions for the files in the RPM, the standard way is to use %defattr and %attr directives in the %files section:
%defattr sets the default attributes for files and folders:
%defattr(<file mode>, <user>, <group>, <dir mode>)
some attributes may be omitted by replacing them with a dash (because the file is installed with those attributes properly set)
%attr sets the attributes for a single file or folder:
%attr(<mode>, <user>, <group>) file/folder
As with %defattr if a particular attribute does not need to be specified, you can replace it with a dash (for example you can use it along with %defattr to keep the default value for that attribute)
A full example:
%files
# set default attributes for all files and folders:
%defattr(644, root, root, 755)
# make a file executable:
%attr(755, -, -) /usr/bin/myexec
# set a different owner for a file:
%attr(-, myuser, -) /var/log/mylog.log
# set different permissions, owner and group for a file:
%attr(600, myuser, mygroup) /home/myfile
For more details & examples you can take a look to:
http://www.rpm.org/max-rpm-snapshot/s1-rpm-specref-files-list-directives.html and
http://www.rpm.org/max-rpm/s1-rpm-anywhere-specifying-file-attributes.html
I don't think changing the umask is what you should be doing. I assume you are unhappy with the permissions on the files coming out of the RPM. For that, you should be using %attr() and %defattr() in your %files section.