Russian WikiWords in FosWiki - locale

I'm trying to set up support for the Russian language wiki. It turns out
nothing. Russian language appears in the texts, but can't configure
WikiWords.
When LocaleRegexes=1, UseLocale=1, Site Locale = ru_RU.utf8 Russian
words are not recognized as the WikiWords. If LocaleRegexes=0 and filled
UpperNational and LowerNational all the Russian words are recognized as
a valid WikiWord. Even in lowercase.
Who can help with the configure wiki?
# uname-a
Linux wiki 3.2.0-24-virtual #37-Ubuntu SMP Wed Apr 25 12:51:49 UTC 2012
i686 i686 i386 GNU/Linux
# perl-v
This is a perl 5, version 14, subversion 2 (v5.14.2) built for
i686-linux-gnu-thread-multi-64int
(with 56 registered patches, see perl-V for more detail)
# locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
# locale-a
C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.iso88591
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
POSIX
ru_RU.iso88591
ru_RU.iso88595
ru_RU.utf8
ru_UA.utf8

This has been asked on the mailing recently. In short:
international WikiWords don't work, sorry.
In fact I'd argue to disable automatic linking of WikiWords all together using
Set NOAUTOLINK = on
in your SitePreferences. Instead, use explicit linking using the bracket notation [[...]].
Then use
$Foswiki::cfg{UseLocale} = 0;
$Foswiki::cfg{Site}{LocaleRegexes} = 1;
$Foswiki::cfg{Ldap}{CharSet} = 'utf-8';
If you still would like to enable locales, then remove the -T flag from all perl scripts.
You can't have both: locales and taintedness checks enabled in perl.
Locales in perl inject a lot of tainted strings coming from the system. As such perl isn't
able to distinguish strings that rightfully should be considered tainted coming from the user.

Related

SELinux AVC Denying "{ dyntransition }" for sshd

I've tried looking around for the solution with no luck.
I have SELinux set to permissive right now on Centos 8, but if I set it to enforcing it completely disables my ability to ssh into the server. This is the journal entry:
setroubleshoot[2015]: setroubleshoot generated AVC, exiting to avoid recursion, context=system_u:system_r:kernel_t:s0, AVC scontext=system_u:system_r:kernel_t:s0
setroubleshoot[2015]: audit event
node=<REMOVED> type=AVC msg=audit(1633374382.599:119): avc: denied { dyntransition } for pid=2003 comm="sshd" scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=1
node=<REMOVED> type=SYSCALL msg=audit(1633374382.599:119): arch=c000003e syscall=1 success=yes exit=42 a0=c a1=5655238d6540 a2=2a a3=0 items=0 ppid=1985 pid=2003 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=3 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:unconfined_r:unconfined_t:s0 key=(null)
/etc/sbin/sshd has the following permissions
-rwxr-xr-x. 1 root root system_u:object_r:sshd_exec_t:s0 877760 May 27 10:54 sshd
This is my sshd config
Port <REMOVED FOR PRIVACY>
AddressFamily inet
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
SyslogFacility AUTHPRIV
PermitRootLogin yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitEmptyPasswords no
PasswordAuthentication no
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem sftp /usr/libexec/openssh/sftp-server
Answering because I lack the rep to comment, le sigh.
The log messages you quote suggest that there is at least one missing SELinux rule on your system: When you try to login via ssh, a transition (dyntransition) from one SELinux type (kernel_t) to another (unconfined_t) is being denied.
There are a couple of commands you can run to investigate:
ausearch -m AVC -m USER_AVC | audit2allow
will look for denial messages and pipe them through a command that will suggest what rules are missing on your system.
sesearch -c process -p dyntransition -A
will tell you what dyntransition rules are already present on your system. You will need to run both of those as root and may need to disable SELinux first (setenforce 0).
What puzzles me is that I find it odd that these permissions would be missing on a stock CentOS box - that suggests either an upstream regression or SELinux policy changes made post-install. Have you or anyone else changed SELinux policy on that box?

bash redirection get err: bad file descriptor and file still open, why?

when I run a simple cmd in bash, I got:
$echo 12312> aaa.txt
-bash: 12312: Bad file descriptor
$lsof aaa.txt
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bash 20647 root 4r REG 8,1 0 1409118 aaa.txt
$bash --version
GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$uname -a
Linux node39 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
is a bug here? I'm not familiar with the bash source code, but I want to
know why. So please give me some tips,best wish to you.
edit:
thx to answer my question, but I really want to know why aaa.txt still opened by
bash after error happend.
spaces - bash is very specific about spaces
echo 1234 > output.txt
int the above example 1234 in written to output.txt using redirection operator >
on the other hand if you omit the spaces
echo 1234> output.txt
redirection operator will treat 1234 as "file descriptor number"

Check Which operating system is installed ( CentOS, Ubuntu, Redhat, ... etc)

I have been given a server with OS installed. I want to check which Operating system is installed in it. I have used uname -a with ouput of
Linux ctl 2.6.32-573.3.1.el6.x86_64 #1 SMP Mon Aug 10 09:44:54 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
Any suggestions ?
You could use the /etc/os-release file, which contains information on the os using the freedesktop spec.
Printing out just the OS name and version:
awk -F '=' '/PRETTY_NAME/ { print $2 }' /etc/os-release
Using os-release file available in Linux:
cat /etc/os-release
on many OS's, you can get the os via:
lsb_release -d
The el6 in the kernel version could indicate a RedHat (thus Fedora as well), Oracle, Centos, Scientific Linux. Potentially others as well.
At least on some of these systems (others as well) the distribution can be identified from the /etc/issue* files. For example:
> ls -la /etc/issue*
-rw-r--r-- 1 root root 57 Oct 22 2014 /etc/issue
-rw-r--r-- 1 root root 55 Oct 22 2014 /etc/issue.net
> cat /etc/issue
Welcome to openSUSE 13.2 "Harlequin" - Kernel \r (\l).
you can try this command to check all detail related to operating system version:
cat /etc/*elease

How can I persistently set the interrupt character in a particular tty?

I was reading this article and was able to set the terminal interrupt character to o using stty intr o.
However, after the first time I used o, the interrupt character would get reset to ^C again.
How can I persist an intr setting on a given tty?
Update with more machine information.
$ bash --version
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ uname -a
Linux <hostname_foobar> 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Update: This appears to only happen if I access to machine above over SSH. I have tested both with key-based login and with password-based login and it reproduces across both cases.

logname unset with input redirection (stdin)

For linux why when providing stdin (input redirection) to logname it is not able to determine the user?
#> echo `logname`
<username>
#> echo `logname` < /dev/null
logname: no login name
#> echo `logname` < /dev/tty
logname: no login name
Moverover this does not seem to affect whoami.
#> echo `whoami`
<username>
#> echo `whoami` < /dev/null
<username>
Edit: Adding OS versions (tested it on multiple different Linux machines).
#> uname -a
Linux <machine1> 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
#> uname -a
Linux <machine2> 2.6.18-238.el5 #1 SMP Sun Dec 19 14:22:44 EST 2010 x86_64 x86_64 x86_64 GNU/Linux
#> uname -a
Linux <machine3> 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) x86_64 x86_64 x86_64 GNU/Linux
On Unix/Linux systems, you can have multiple users logged in through different windows, ssh sessions etc. Each currently logged in user may or may not have a tty associated with the session. If there is a tty session allocated for a user, the association between tty and the user logged in on it is stored in the systems utmp file (the path may vary). logname wants to first see what tty you are on, then look up the associated record in the utmp file to see who you are. When you do logname < /dev/null, logname is disassociated from your tty, and so fails to find out which record it needs to lookup, which is why it reports "no login name".

Resources