https://www.funtoo.org/api.php?action=feedcontributions&user=Lautriv2&feedformat=atomFuntoo - User contributions [en]2024-03-29T11:49:13ZUser contributionsMediaWiki 1.36.2https://www.funtoo.org/index.php?title=Getty_as_display_manager&diff=9812Getty as display manager2015-05-04T07:14:41Z<p>Lautriv2: /* Autologin */</p>
<hr />
<div>This guide shows how you can use getty as display manager.<br />
<br />
== Choose window manager ==<br />
<br />
If you use <code>fi</code> keyboard layout and <code>dwm</code> as window manager, you would set the following in your <code>~/.xinitrc</code>:<br />
<br />
{{file|name=~/.xinitrc|desc=setting up keyboard layout and window manager|body=<br />
setxkbmap fi<br />
exec dwm<br />
}}<br />
<br />
== Start X on login to tty1 ==<br />
<br />
Start X session when you login to first virtual terminal.<br />
<br />
Add the following line in top of your <code>~/.bashrc</code>:<br />
<br />
{{file|name=~/.bashrc|desc=Autostart X on login to tty1|body=<br />
[[ $(tty) = "/dev/tty1" ]] && exec startx<br />
}}<br />
<br />
== Autologin ==<br />
<br />
Modify <code>/etc/inittab</code>:<br />
<br />
{{file|name=/etc/inittab|desc=Autologin|body=<br />
# TERMINALS<br />
c1:12345:respawn:/sbin/agetty -a username 38400 tty1 linux<br />
}}<br />
{{important|If you want start X straight from autologin in inittab, enter the code from the above .bashrc in ~/.bash_profile instead.}}<br />
[[Category:HOWTO]][[Category:Display_Managers]]</div>Lautriv2https://www.funtoo.org/index.php?title=Nfs&diff=9642Nfs2015-04-13T17:28:24Z<p>Lautriv2: /* Installation */</p>
<hr />
<div>= NFS =<br />
<br />
This wiki will explain how to install and use nfs on funtoo, before we start a little hint for those who already searched for information :<br />
<br />
Recent linux has NO need to do any tunings like suggested in the old days, like there was often mentioned playing with rsize and wsize parameters and such.<br />
If you don't run outdated kernel/userland, which is unlikely since funtoo was not there that time, all neccessary parameters are dynamically controlled by the<br />
kernel and will exceed the old values by far, hence you may not wonder if "mount" returns values which are 100 times greater than you expected.<br />
<br />
These Days we differ usually between NFS V3 and NFS V4 which has nothing in common but the name. Older variants are weak,error prone, insecure etc.<br />
and are not mentioned any longer.<br />
<br />
If you plan to setup a new NFS Server, i would strongly recomment V4 because it has several advantages over V3.<br />
<br />
== Installation ==<br />
<br />
In general, you need a kernel with NFS enabled modules or built in, those settings can be found in "File systems" ->"Network file systems" using make menuconfig.<br />
<br />
For generic client functionality you need<br />
<br />
{{console|body=<br />
###i## emerge net-fs/libnfs<br />
###i## emerge net-fs/nfs-utils<br />
}}<br />
<br />
This will give you the neccessary tools and environment to mount some NFS from a server or start a server on the machine itself.<br />
<br />
NFS V3 can take care about disappearing and re-appearing machines on the network and deal accordingly with locked files and timeouts, to achieve that, you want to<br />
<br />
{{console|body=<br />
###i## rc-update add rpc.statd default<br />
###i## rc<br />
}}<br />
<br />
the first time you installed it, will be automatic on reboot.<br />
This is not neccessary on pure V4 environments but since it can't be autodetected the rc-script will force it. If you won't use V 3 at all, you may remove it from the scripts depencencies<br />
by editing /etc/init.d/nfs and /etc/init.d/nfsmount and remove "rpc.statd" from need .<br />
<br />
== Exporting V3 syntax ==<br />
<br />
If you consider to use only V3, you need to add some exported directories in /etc/exports, this can be something like this :<br />
<br />
{{file|name=/etc/exports|desc=NFS V3 export syntax|body=<br />
...<br />
10.0.0.0/8 /absolute/path/to/desired/dir (rw,async)<br />
some.domain.tld /another/full/path/to/dir2 (ro,async)<br />
...<br />
}}<br />
<br />
and several alternative globbings with additional options where "man exports" gives you a good overview. One of the biggest differences to V4 ( see below ) in exporting dirs<br />
is the fact you write absolute paths ( from / downwards to the dir ) and V3 cares not about about username but uid.<br />
<br />
{{important|NFS V3 is mapping uids on the exported files and dirs, this can become cumbersome on networks with different uids on the clients}}<br />
<br />
== Exporting V4 syntax ==<br />
<br />
If you consider to use V4, you need to add exported directories in a different way, there is only one NFSROOT and all other dirs have to appear below that :<br />
<br />
{{file|name=/etc/exports|desc=NFS V4 export syntax|body=<br />
...<br />
10.0.0.0/8 /srv (fsid=0,rw,async,no_root_squash,no_all_squash)<br />
some.domain.tld /srv/dir2 (ro,async)<br />
...<br />
}}<br />
<br />
In this situation, we define the root of your nfs to be /srv ( latest V4 will take the first entry, early V4 used the above fsid=0 to mark it. This is considered deprecated but doesn't harm ).<br />
Also, we define another dir below NFSROOT, here /srv/dir2 which is meant to be mounted relative. ( See below ). You may mount a dir that exists somewhere else but in that case you<br />
need to bind-mount it for V4. e.g. if you want to export /mnt/another, you get this done by<br />
<br />
{{console|body=<br />
###i##mkdir /srv/dir2<br />
###i##mount -o bind /mnt/another /srv/dir2<br />
}}<br />
<br />
If you do so, remember to add the mount also in fstab for next reboot :<br />
{{console|body=<br />
##y##/srv/dir2 /mnt/another bind defaults 0 0<br />
}}<br />
<br />
== Activate changes on servers ==<br />
<br />
Whenever you add or change settings in /etc/exports, there is no need to restart the server(s), else just<br />
<br />
{{console|body=<br />
###i##exportfs -rv<br />
}}<br />
<br />
== ID mapping ==<br />
<br />
Like mentioned above, V4 does not care any longer for uids but will use username@machine instead. This is a big improvement since we must not longer care about the order of given users when adding accounts. However, if for some reason the protocol version 4 becomes inappropirate ( old client, bad parameters etc.) it will automatically fall back to use V3 where we need a way to get the different behaviour somehow mapped, this is also the case in mixed environments and such where we have a solution thisfor. If you plan to use V4, you want to :<br />
<br />
{{console|body=<br />
###i##emerge net-libs/libnfsidmap<br />
###i##rc-update add rpc.idmapd default<br />
###i##rc<br />
}}<br />
<br />
which will care about such situations.<br />
<br />
== Mounting V3 export from clients ==<br />
<br />
Using V3, you have to specify the server and it's absolute path to the exported dir, this can be by IP like this :<br />
<br />
{{console|body=<br />
###i##mount -t nfs 10.0.8.254:/my/absolute/path/to/mounting/location /somewhere<br />
}}<br />
<br />
Or you may use a hostname or FQDN but only if you have a proper setup to resolve that reproducible from the client ( e.g. enty in /etc/hosts or local DNS servers etc. ) :<br />
<br />
{{console|body=<br />
###i##mount -t nfs nfsserver:/my/absolute/path/to/mounting/location /somewhere<br />
}}<br />
<br />
Mounted via fstab, this would look like :<br />
{{console|body=<br />
##y##/somewhere 10.0.8.254:/my/absolute/path/to/mounting/location nfs defaults 0 0<br />
##y##/somewhere nfsserver:/my/absolute/path/to/mounting/location nfs defaults 0 0<br />
}}<br />
<br />
the usage of IPs is recommented for machines mounting their own root on NFS to avoid early resolving issues.<br />
<br />
== Mounting V4 export from clients ==<br />
<br />
Using V4, you DONT specify the absolute path, else it will fall back to V3 :<br />
<br />
{{console|body=<br />
###i##mount -t nfs4 10.0.8.254:/dir2 /somewhere<br />
}}<br />
<br />
( Above example exported by /srv/dir2 aka $NFSROOT/dir2 )<br />
You may also use a hostname or FQDN <br />
<br />
and in fstab :<br />
<br />
{{console|body=<br />
##y##/somewhere 10.0.8.254:/dir2 nfs4 defaults 0 0<br />
##y##/somewhere nfsserver:/dir2 nfs4 defaults 0 0<br />
}}<br />
<br />
== Hints ==<br />
<br />
The use of -t nfs resp -t nfs4 is most likely redundant, recent userland has a good autodetection.<br />
If not specially mentioned, nfs will map your users to nobody:nogroup, if you want to differ them on exported dirs, use the above mentioned "no_all_squash" option,<br />
The local user root is not neccessarly the same superuser like on the server, if you want him to be the same, use "no_root_squash" else he is nobody ;)</div>Lautriv2https://www.funtoo.org/index.php?title=Nfs&diff=9641Nfs2015-04-13T17:07:30Z<p>Lautriv2: Created page with "= NFS = This wiki will explain how to install and use nfs on funtoo, before we start a little hint for those who already searched for information : Recent linux has NO need..."</p>
<hr />
<div>= NFS =<br />
<br />
This wiki will explain how to install and use nfs on funtoo, before we start a little hint for those who already searched for information :<br />
<br />
Recent linux has NO need to do any tunings like suggested in the old days, like there was often mentioned playing with rsize and wsize parameters and such.<br />
If you don't run outdated kernel/userland, which is unlikely since funtoo was not there that time, all neccessary parameters are dynamically controlled by the<br />
kernel and will exceed the old values by far, hence you may not wonder if "mount" returns values which are 100 times greater than you expected.<br />
<br />
These Days we differ usually between NFS V3 and NFS V4 which has nothing in common but the name. Older variants are weak,error prone, insecure etc.<br />
and are not mentioned any longer.<br />
<br />
If you plan to setup a new NFS Server, i would strongly recomment V4 because it has several advantages over V3.<br />
<br />
== Installation ==<br />
<br />
In general, you need a kernel with NFS enabled modules or built in, those settings can be found in "File systems" ->"Network file systems" using make menuconfig.<br />
<br />
For generic client functionality you need<br />
<br />
{{console|body=<br />
###i## emerge net-fs/libnfs<br />
###i## emerge net-fs/nfs-utils<br />
}}<br />
<br />
This will give you the neccessary tools and environment to mount some NFS from a server or start a server on the machine itself.<br />
<br />
NFS can take care about disappearing and re-appearing machines on the network and deal accordingly with locked files and timeouts, to achieve that, you want to<br />
<br />
{{console|body=<br />
###i## rc-update add rpc.statd default<br />
###i## rc<br />
}}<br />
<br />
the first time you installed it, will be automatic on reboot.<br />
<br />
== Exporting V3 syntax ==<br />
<br />
If you consider to use only V3, you need to add some exported directories in /etc/exports, this can be something like this :<br />
<br />
{{file|name=/etc/exports|desc=NFS V3 export syntax|body=<br />
...<br />
10.0.0.0/8 /absolute/path/to/desired/dir (rw,async)<br />
some.domain.tld /another/full/path/to/dir2 (ro,async)<br />
...<br />
}}<br />
<br />
and several alternative globbings with additional options where "man exports" gives you a good overview. One of the biggest differences to V4 ( see below ) in exporting dirs<br />
is the fact you write absolute paths ( from / downwards to the dir ) and V3 cares not about about username but uid.<br />
<br />
{{important|NFS V3 is mapping uids on the exported files and dirs, this can become cumbersome on networks with different uids on the clients}}<br />
<br />
== Exporting V4 syntax ==<br />
<br />
If you consider to use V4, you need to add exported directories in a different way, there is only one NFSROOT and all other dirs have to appear below that :<br />
<br />
{{file|name=/etc/exports|desc=NFS V4 export syntax|body=<br />
...<br />
10.0.0.0/8 /srv (fsid=0,rw,async,no_root_squash,no_all_squash)<br />
some.domain.tld /srv/dir2 (ro,async)<br />
...<br />
}}<br />
<br />
In this situation, we define the root of your nfs to be /srv ( latest V4 will take the first entry, early V4 used the above fsid=0 to mark it. This is considered deprecated but doesn't harm ).<br />
Also, we define another dir below NFSROOT, here /srv/dir2 which is meant to be mounted relative. ( See below ). You may mount a dir that exists somewhere else but in that case you<br />
need to bind-mount it for V4. e.g. if you want to export /mnt/another, you get this done by<br />
<br />
{{console|body=<br />
###i##mkdir /srv/dir2<br />
###i##mount -o bind /mnt/another /srv/dir2<br />
}}<br />
<br />
If you do so, remember to add the mount also in fstab for next reboot :<br />
{{console|body=<br />
##y##/srv/dir2 /mnt/another bind defaults 0 0<br />
}}<br />
<br />
== Activate changes on servers ==<br />
<br />
Whenever you add or change settings in /etc/exports, there is no need to restart the server(s), else just<br />
<br />
{{console|body=<br />
###i##exportfs -rv<br />
}}<br />
<br />
== ID mapping ==<br />
<br />
Like mentioned above, V4 does not care any longer for uids but will use username@machine instead. This is a big improvement since we must not longer care about the order of given users when adding accounts. However, if for some reason the protocol version 4 becomes inappropirate ( old client, bad parameters etc.) it will automatically fall back to use V3 where we need a way to get the different behaviour somehow mapped, this is also the case in mixed environments and such where we have a solution thisfor. If you plan to use V4, you want to :<br />
<br />
{{console|body=<br />
###i##emerge net-libs/libnfsidmap<br />
###i##rc-update add rpc.idmapd default<br />
###i##rc<br />
}}<br />
<br />
which will care about such situations.<br />
<br />
== Mounting V3 export from clients ==<br />
<br />
Using V3, you have to specify the server and it's absolute path to the exported dir, this can be by IP like this :<br />
<br />
{{console|body=<br />
###i##mount -t nfs 10.0.8.254:/my/absolute/path/to/mounting/location /somewhere<br />
}}<br />
<br />
Or you may use a hostname or FQDN but only if you have a proper setup to resolve that reproducible from the client ( e.g. enty in /etc/hosts or local DNS servers etc. ) :<br />
<br />
{{console|body=<br />
###i##mount -t nfs nfsserver:/my/absolute/path/to/mounting/location /somewhere<br />
}}<br />
<br />
Mounted via fstab, this would look like :<br />
{{console|body=<br />
##y##/somewhere 10.0.8.254:/my/absolute/path/to/mounting/location nfs defaults 0 0<br />
##y##/somewhere nfsserver:/my/absolute/path/to/mounting/location nfs defaults 0 0<br />
}}<br />
<br />
the usage of IPs is recommented for machines mounting their own root on NFS to avoid early resolving issues.<br />
<br />
== Mounting V4 export from clients ==<br />
<br />
Using V4, you DONT specify the absolute path, else it will fall back to V3 :<br />
<br />
{{console|body=<br />
###i##mount -t nfs4 10.0.8.254:/dir2 /somewhere<br />
}}<br />
<br />
( Above example exported by /srv/dir2 aka $NFSROOT/dir2 )<br />
You may also use a hostname or FQDN <br />
<br />
and in fstab :<br />
<br />
{{console|body=<br />
##y##/somewhere 10.0.8.254:/dir2 nfs4 defaults 0 0<br />
##y##/somewhere nfsserver:/dir2 nfs4 defaults 0 0<br />
}}<br />
<br />
== Hints ==<br />
<br />
The use of -t nfs resp -t nfs4 is most likely redundant, recent userland has a good autodetection.<br />
If not specially mentioned, nfs will map your users to nobody:nogroup, if you want to differ them on exported dirs, use the above mentioned "no_all_squash" option,<br />
The local user root is not neccessarly the same superuser like on the server, if you want him to be the same, use "no_root_squash" else he is nobody ;)</div>Lautriv2https://www.funtoo.org/index.php?title=Package:Tengine&diff=9587Package:Tengine2015-04-10T19:20:08Z<p>Lautriv2: </p>
<hr />
<div>{{Ebuild<br />
|Summary=Robust, small and high performance http and reverse proxy server<br />
|CatPkg=www-servers/tengine<br />
|Homepage=http://tengine.taobao.org<br />
}}<br />
Tengine is an {{package|www-servers/nginx}} fork. It supports DSO module loading, meaning it can have external modules without the need to compile them in. <br />
<br />
===Installation===<br />
==== Shared & Static Modules ====<br />
If you happen to want all modules installed dynamically, you, still, need to install some static modules. Make sure to add this to your {{c|/etc/portage/make.conf}} file:<br />
<br />
{{file|name=/etc/portage/make.conf|desc=Tengine all-modules build|body=<br />
...<br />
TENGINE_SHARED_MODULES_HTTP="access addition autoindex browser charset_filter empty_gif fastcgi flv footer_filter geoip image_filter limit_conn limit_req lua map memcached mp4 random_index referer reqstat rewrite scgi secure_link slice split_clients sub sysguard tfs trim_filter upstream_ip_hash upstream_least_conn upstream_session_sticky user_agent userid_filter uwsgi xslt"<br />
TENGINE_STATIC_MODULES_HTTP="concat dav degradation geo gunzip gzip gzip_static perl proxy realip spdy ssi ssl stub_status upstream-rbtree upstream_check upstream_consistent_hash upstream_keepalive"<br />
...<br />
}}<br />
<br />
==== External Modules ====<br />
If you want to run passenger:<br />
{{file|name=/etc/portage/make.conf|desc=build the passenger module|body=<br />
TENGINE_EXTERNAL_MODULES_HTTP="passenger"<br />
}}<br />
<br />
Then, just: <br />
{{console|body=###i## emerge tengine}}<br />
<br />
===Configuration===<br />
Files for configuration are located at {{c|/etc/tengine}}<br />
<br />
The major differing point in tengine from nginx is that you have to specifically declare which modules are loaded. Available modules are located at {{c|/var/lib/tengine/modules}}.<br />
<br />
{{file|name=/etc/tengine/tengine.conf|desc=DSO module statements|body=<br />
...<br />
dso {<br />
load ngx_http_charset_filter_module.so;<br />
load ngx_http_fastcgi_module.so;<br />
load ngx_http_rewrite_module.so;<br />
load ngx_http_access_module.so; ## added because you want most likely use allow & deny on certain positions<br />
}<br />
...<br />
}}<br />
<br />
===Tengine===<br />
{{c|/etc/tengine/tengine.conf}} contains engine specific configurations.<br />
<br />
===Sites===<br />
{{c|/etc/tengine/sites-available/localhost}} has site specific configurations. Generally localhost is copied to domain.tld file formats in the {{c|/etc/tengine/sites-available/}} directory.<br />
<br />
===Redirection===<br />
These days, it is usual to have anything on https to protect your users regarding login and privacy where it comes handy to automatically redirect requests from http which are often a result of the browsers autocompletion. To achieve that, we need a server listening on http and redirecting to our main server on https like this :<br />
<br />
{{file|name=/etc/tengine/sites-available/redir|desc=redirection from http to https|body=<br />
<br />
server {<br />
server_name domain.tld;<br />
listen 80;<br />
return 302 https://www.domain.tld$request_uri;<br />
}<br />
}}<br />
<br />
===PHP-FPM===<br />
Tengine does not natively support php, so we delegate that responsibility to [[Package:PHP#Fpm | php-fpm]]<br />
<br />
{{file|name=/etc/tengine/sites-available/localhost|desc=fpm tcp/ip configuration|body=<br />
server {<br />
...<br />
index index.php index.cgi index.htm index.html;<br />
location ~ \.php$ {<br />
fastcgi_pass 127.0.0.1:9000;<br />
include fastcgi.conf;<br />
}<br />
...<br />
}<br />
}}<br />
<br />
===Usage===<br />
To start the tengine server:<br />
<br />
{{console|body=###i## rc-update add tengine default<br />
###i## rc}}<br />
{{EbuildFooter}}</div>Lautriv2https://www.funtoo.org/index.php?title=Package:Tengine&diff=9571Package:Tengine2015-04-10T12:52:38Z<p>Lautriv2: </p>
<hr />
<div>{{Ebuild<br />
|Summary=Robust, small and high performance http and reverse proxy server<br />
|CatPkg=www-servers/tengine<br />
|Homepage=http://tengine.taobao.org<br />
}}<br />
Tengine is an {{package|www-servers/nginx}} fork. It supports DSO module loading, meaning it can have external modules without the need to compile them in. <br />
<br />
===Installation===<br />
==== Shared & Static Modules ====<br />
If you happen to want all modules installed dynamically, you, still, need to install some static modules. Make sure to add this to your {{c|/etc/portage/make.conf}} file:<br />
<br />
{{file|name=/etc/portage/make.conf|desc=Tengine all-modules build|body=<br />
...<br />
TENGINE_SHARED_MODULES_HTTP="access addition autoindex browser charset_filter empty_gif fastcgi flv footer_filter geoip image_filter limit_conn limit_req lua map memcached mp4 random_index referer reqstat rewrite scgi secure_link slice split_clients sub sysguard tfs trim_filter upstream_ip_hash upstream_least_conn upstream_session_sticky user_agent userid_filter uwsgi xslt"<br />
TENGINE_STATIC_MODULES_HTTP="concat dav degradation geo gunzip gzip gzip_static perl proxy realip spdy ssi ssl stub_status upstream-rbtree upstream_check upstream_consistent_hash upstream_keepalive"<br />
...<br />
}}<br />
<br />
==== External Modules ====<br />
If you want to run passenger:<br />
{{file|name=/etc/portage/make.conf|desc=build the passenger module|body=<br />
TENGINE_EXTERNAL_MODULES_HTTP="passenger"<br />
}}<br />
<br />
{{important|Actual version of tengine complains about a missing group and fails to configure, just "groupadd tengine" before you emerge.}}<br />
<br />
Then, just: <br />
{{console|body=###i## emerge tengine}}<br />
<br />
===Configuration===<br />
Files for configuration are located at {{c|/etc/tengine}}<br />
<br />
The major differing point in tengine from nginx is that you have to specifically declare which modules are loaded. Available modules are located at {{c|/var/lib/tengine/modules}}.<br />
<br />
{{file|name=/etc/tengine/tengine.conf|desc=DSO module statements|body=<br />
...<br />
dso {<br />
load ngx_http_charset_filter_module.so;<br />
load ngx_http_fastcgi_module.so;<br />
load ngx_http_rewrite_module.so;<br />
load ngx_http_access_module.so; ## added because you want most likely use allow & deny on certain positions<br />
}<br />
...<br />
}}<br />
<br />
===Tengine===<br />
{{c|/etc/tengine/tengine.conf}} contains engine specific configurations.<br />
<br />
===Sites===<br />
{{c|/etc/tengine/sites-available/localhost}} has site specific configurations. Generally localhost is copied to domain.tld file formats in the {{c|/etc/tengine/sites-available/}} directory.<br />
<br />
===Redirection===<br />
These days, it is usual to have anything on https to protect your users regarding login and privacy where it comes handy to automatically redirect requests from http which are often a result of the browsers autocompletion. To achieve that, we need a server listening on http and redirecting to our main server on https like this :<br />
<br />
{{file|name=/etc/tengine/sites-available/redir|desc=redirection from http to https|body=<br />
<br />
server {<br />
server_name domain.tld;<br />
listen 80;<br />
return 302 https://www.domain.tld$request_uri;<br />
}<br />
}}<br />
<br />
===PHP-FPM===<br />
Tengine does not natively support php, so we delegate that responsibility to [[Package:PHP#Fpm | php-fpm]]<br />
<br />
{{file|name=/etc/tengine/sites-available/localhost|desc=fpm tcp/ip configuration|body=<br />
server {<br />
...<br />
index index.php index.cgi index.htm index.html;<br />
location ~ \.php$ {<br />
fastcgi_pass 127.0.0.1:9000;<br />
include fastcgi.conf;<br />
}<br />
...<br />
}<br />
}}<br />
<br />
===Usage===<br />
To start the tengine server:<br />
<br />
{{console|body=###i## rc-update add tengine default<br />
###i## rc}}<br />
{{EbuildFooter}}</div>Lautriv2