Several identical machines all running Fedora 21 in a cluster are all exhibiting identical issues:
Attempting to pull a user journal with journalctl -r gives:
No journal files were opened due to insufficient permissions.
Trying journalctl --user -r gives:
No journal files were found.
Checking in /var/log/journal/[whatever] yields system journals (which seem to work fine as root) and one or two user journals. Logging in as a user that has a user journal in this directory shows that these users can pull their own journal just fine.
It seems like journals are being created for some users but not others. I can find nothing different about the users with journals, and it's not the same users exhibiting the problem on every system, despite identical /etc/passwd, /etc/group, and /etc/shadow files across the systems.
All of this worked fine on Fedora 20.
I believe this is related to this question.
I had this issue on Ubuntu 17.10. One of my users could view his journal entries, but another couldn't. The issue was resolved by changing the Storage directive of the [Journal] section of /etc/systemd/journald.conf to persistent:
Edit journald.conf
$ sudo vi /etc/systemd/journald.conf
Original Config
[Journal]
#Storage=auto
...
New Config
[Journal]
Storage=persistent
...
After a restart of journalctl, all users could view their respective logs:
$ sudo systemctl restart systemd-journald
Related
As explained I want to set up a PostgreSQL database (specifically for Metasploit to use as I'm running my own install of arch instead of kali linux). I have followed the instructions so far to the best of my ability although I don't have any experience with PostgreSQL or much in databases for that matter and am stuck on this error.
As you can see the server was able to be initialised at least but I don't know how to/can't get it to start.
[postgres#rt metasploit]$ initdb --locale=C --encoding=UTF8 -D /var/lib/postgres/data --data-checksums
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "C".
The default text search configuration will be set to "english".
Data page checksums are enabled.
creating directory /var/lib/postgres/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Etc/GMT-2
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
Success. You can now start the database server using:
pg_ctl -D /var/lib/postgres/data -l logfile start
[postgres#rt metasploit]$ pg_ctl -D /var/lib/postgres/data -l logfile start
waiting for server to start..../bin/sh: line 1: logfile: Permission denied
stopped waiting
pg_ctl: could not start server
Examine the log output.
If this is a noob question please just link me to the answer, as I said I have little to no experience working with databases and just want to get it up and running. I tried searching for it myself but couldn't find much of help.
I prompted a failed su attemp in order to observe the log.
However, I couldn't find where su writes its logs.
My box is Kali 2019.
I commented out the SULOG section in my /etc/login.defs file
# If defined, all su activity is logged to this file.
#
SULOG_FILE /var/log/sulog
Despite having done that I still don't have sulog file in /var/log.
I created one manually and made the wrong attempt again but nothing.
I am missing something?
Thank you all in advance.
many times, login attempts or request for a new login shell are logged into os mailbox and/or on your system log.
It depend on your os default configs.
Try to check file:
/var/spool/mail/
or try:
journalctl -r
to see all your system log starting by newest
In some beta version of Arangodb 3.4 my database crashed while I tried to add a view via arangosh. Because I were not able to start the database anymore, it was not possible to make a backup (database dump).
I just wanted to install the newest Arangodb 3.4.2.1 then, but that failed because my CPU was to old (no SSE 4.2 support). So I bought a new computer, sat up a new linux, copied the databases to /var/lib/arangodb3/databases, started a new installation of Arangodb in which it even asked me, if the current databases should be upraded. I confirmed that.
Unfortunately it hasn't found the databases in that directory, so I have now just acces to the system database.
My question is: Can I recover the databases which are laying in /var/lib/arangodb3/databases somehow?
Do you have a copy of the "var/lib/arangodb3" directory (which includes "databases" as a subfolder) as well? If so, copy the folder to a location on your new machine where Arangodb 3.4.2.1 is installed. You also have to make sure to give the user arangodb access to this folder with the following command:
chown -R arangodb:arangodb /path/to/your/arangodb3RecoveryFolder
Next you can modify the arangod.conf (located at /etc/arangodb3/arangod.conf) to point to your recovery arangodb3 folder.
[database]
directory = /path/to/your/arangodb3RecoveryFolder
Then stop the arangodb3 service with sudo service arangodb3 stop,
run sudo service arangodb3 upgrade to upgrade the database directory and sudo service arangodb3 start to start the service again.
You can check if the service is running by executing sudo service arangodb3 status. In case it is not working, have a look at potential error messages in the log file (/var/log/arangodb3/arangod.log).
My Issue
I am having trouble removing MongoDB warnings about Transparent Huge Pages (THP) on an OVH CentOS 7 installation, and the issue appears to be the inability to write to /sys/kernel/mm as root.
First, I realize the OVH kernel is customized, and I know many of you will say to go with a fresh non-customized kernel, but that's not an option right now. I need to solve this problem for the current OS.
MongoDB Warnings:
2016-03-09T00:31:45.889-0500 W CONTROL [initandlisten] Failed to probe "/sys/kernel/mm/transparent_hugepage": Permission denied
2016-03-09T00:31:45.889-0500 W CONTROL [initandlisten] Failed to probe "/sys/kernel/mm/transparent_hugepage": Permission denied
MongoDB is trying to read the transparent_hugepage files (below), but they do not exist:
/sys/kernel/mm/transparent_hugepage/enabled
/sys/kernel/mm/transparent_hugepage/defrag
Cannot Create the Files
All of the solutions I've seen involve creating the files and populating them with never, including the script in the MongoDB documentation. In all of the solutions, this is the key part:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
However, the files do not exist, and I cannot create anything under /sys/kernel/mm as root.
root#myhost [~]# echo never > /sys/kernel/mm/transparent_hugepage/enabled
-bash: /sys/kernel/mm/transparent_hugepage/enabled: No such file or directory
root#myhost [~]# mkdir -p /sys/kernel/mm/transparent_hugepage
mkdir: cannot create directory ‘/sys/kernel/mm/transparent_hugepage’: Operation not permitted
The owner and group of directory /sys/kernel/mm are root, and I have temporarily changed the permissions from 700 to 777, yet I still cannot create the directory as root.
Tuned Profile Also Doesn't Help
To be thorough, I have also created the custom Tuned profile (per instructions in MongoDB link above) and activated it, but it generates the error WARNING tuned.plugins.plugin_vm: Option 'transparent_hugepages' is not supported on current hardware.
Tuned Profile (/etc/tuned/no-thp/tuned.conf):
[main]
include=virtual-guest
[vm]
transparent_hugepages=never
Error in Tuned log:
WARNING tuned.plugins.plugin_vm: Option 'transparent_hugepages' is not supported on current hardware.
Some Solution in MongoDB Itself?
It seems like the best solution would be to somehow explicitly configure MongoDB not to use THP so that it wouldn't have to check for the missing files, but I've seen nothing like this. If there is a way, even if it involves customizing MongoDB (and repeating after every update), I'm willing to do it.
Right now I've installed CentOS 7 on OVH. They use /boot/bzImage-3.14.32-xxxx-grs-ipv6-64 that implements grsecurity (https://grsecurity.net) which precludes access to some folders.
The very simple solution to the warnings from MongoDB about huge pages can be solved by replacing the kernel. The procedure for CentOS7 is as follows:
Download required kernel from OVH ftp: ftp://ftp.ovh.net/made-in-ovh/bzImage2 into /boot folder.
Edit /etc/grub2.cfg:
# linux /boot/bzImage-3.14.32-xxxx-grs-ipv6-64 root=/dev/md1 ro net.ifnames=0
linux /boot/bzImage-4.8.17-xxxx-std-ipv6-64 root=/dev/md1 ro net.ifnames=0
Here I replaced bzImage-3.14.32-xxxx-grs-ipv6-64 default by bzImage-4.8.17-xxxx-std-ipv6-64 without grs.
Now, reboot and check if the new kernel is ok:
root#ns506846 ~]# uname -r
4.8.17-xxxx-std-ipv6-64
Agenda: To have an common Project Folder between Linux and Windows
I have changed my document root from : /var/www/html to /media/mithun/Projects/test in my ubuntu machine 14.04
I get error as :
Forbidden
You don't have permission to access / on this server.
Apache/2.4.7 (Ubuntu) Server at localhost Port 80
So i added some scripts to : sudo gedit /etc/apache2/sites-available/000-default.conf
# DocumentRoot /var/www/html
DocumentRoot /media/mithun/Projects/test
But Document Root /var/www/test works but not with Windows NTFS Partition Drive.
Even after referring to :
Error message "Forbidden You don't have permission to access / on this server"
Issue with my Ubuntu Apache Conf file. (Forbidden You don't have permission to access / on this server.)
No success :( So kindly assist me with it...
Note: Projects is an New Volume (Internal Drive: In Windows its E:/ Drive)
#Lmwangi - Please check my updates for your reference below:
Output of : ls /etc/apparmor.d/
abstractions lightdm-guest-session usr.bin.evince usr.sbin.cupsd
cache local usr.bin.firefox usr.sbin.mysqld
disable sbin.dhclient usr.lib.telepathy usr.sbin.rsyslogd
force-complain tunables usr.sbin.cups-browsed usr.sbin.tcpdump
I tried killing apparmor:
sudo /etc/init.d/apparmor kill
I receive output as : Usage: /etc/init.d/apparmor
{start|stop|restart|reload|force-reload|status|recache}
After this, i was also able to restart apache successfully
maybe the problem is simple : is your new root directory accessible to the www-data user ?
Try :
$ chown -R www-data:www-data /media/mithun/Projects
As you have you have discovered by now, you cannot just manipulate permissions on an NTFS partition (using tools like chmod)
However, you can try forcing a given owner/permissions for the entire partition when you mount it.
Now the wayto do this, depends on the NTFS-utilities you are actually using (and which i don't know, so I'm assuming you are using ntfs-3g)
E.g. mount the partition with the following parameters (replace dev/sdX with your actual partition, and /path/to/wheredrive/is/mounted` with your target path):
mount -o gid=www-data /dev/sdX /path/where/the/drive/is/mounted
should make all the files on the partition belong to the www-data group.
If the filesystem sets the group ownership explicitely, this still might not work.
In this case, you might need to setup a usermap, that maps your windows users/groups (as found on the partition) to your linux users/groups.
The ntfs-3g.usermap utility will help you generate an initial usermap file, which you can then edit to your needs:
ntfs-3g.usermap /dev/sdX
Then pass the usermap to the mount options:
mount -o usermapping=/path/to/usermap.file /dev/sdX /path/where/the/drive/is/mounted
I suspect that you have apparmor enforcing rules that prevent Apache from reading non-whitelisted directory paths. I suggest that you
Edit the apparmor config for Apache to access your custom path. You'll need to hunt around /etc/apparmor.d/ . You may also find that using apparmor in non-enforcing mode helpful.
$ sudo aa-complain /etc/apparmor.d/*
Use mod_apparmor? See this
Or disable apparmor completely. See this
My order of preference would be 1,3,2. That should fix this for you :)
While using ubuntu with windows I faced same issue and it is resolved by remounting drive with read and write access. Below command will help you to do that:
sudo mount -o remount,rw /disk/location /disk/new_location
If it is still not working then in windows os, go to the power options and disable fast startup.
When you shut down a computer with Fast Startup enabled, Windows locks down the Windows hard disk. You won’t be able to access it from other operating systems if you have your computer configured to dual-boot. Even worse, if you boot into another OS and then access or change anything on the hard disk (or partition) that the hibernating Windows installation uses, it can cause corruption. If you’re dual booting, it’s best not to use Fast Startup or Hibernation at all.
Original article: https://www.howtogeek.com/243901/the-pros-and-cons-of-windows-10s-fast-startup-mode/