gripfly
-
Posts
17 -
Joined
-
Last visited
Reputation Activity
-
gripfly reacted to SansVarnic in Fetching new mails | Sending mails via Telegram
Never heard of the software until I read this just now.
It is possible someone may know, its hard to say. Please be patient.
I suggest you bump the topic, but you can only do this once every 24hrs.
-= Topic moved to Programs, Apps and Websites =-
This may get better results for you.
-
gripfly reacted to Nayr438 in Default gateway and Plex Media Server
I am not familiar with plex or any media servers, so I probably wont be as much help there.
The most I can offer is a link to there article for Remote Access.
https://support.plex.tv/articles/200289506-remote-access/
-
gripfly reacted to Nayr438 in Default gateway and Plex Media Server
That would just be whatever ip address you want to assign on your local network for that device. You wont have to configure anything on your router.
So for a gateway of 192.168.0.1 , a ip like 192.168.0.25 would be fine, so long as another device isn't using it.
-
gripfly reacted to Nayr438 in Default gateway and Plex Media Server
If your running Kubuntu on it, just edit the network connection and make it static.
System Settings -> Connections -> IPV4 -> Manual Otherwise I would just use dhcpcd and setup a static profile. You would need to disable your current network manager, which I assume is NetworkManager.
https://wiki.archlinux.org/index.php/dhcpcd
http://manpages.ubuntu.com/manpages/trusty/man8/dhcpcd5.8.html
-
gripfly reacted to plus in Installing an UPS
Hi,
sounds like your distro loaded / included apcupsd instead of nut for handling UPS.
apcupsd works great - for APC devices, but reporting zero values seems to be a common thing for some Eaton models.
You can find out if that's the case by the output of "sudo apcaccess". If it is present and displays the same wrong values, you're running apcupsd.
I've read that switching to "nut" (package "network UPS tools") shows better results with Eaton devices.
-
gripfly reacted to Dutch_Master in Raid array vanishes after reboot
Good, glad you got it sorted!
Another pro-tip:
sudo su This gives you a semi-persistent root shell, until you close the terminal. Meaning, all commands that require root privileges can be run w/o the sudo prefix.
-
gripfly reacted to Dutch_Master in Raid array vanishes after reboot
Right, then we're going in deep!
First, determine what group your normal user has:
groups #execute as normal user Let's say for the sake of this intro your regular user name is gripfly. If you see that appearing in the output of the above command, your username is also a group. Next, invoke the chgrp command as root:
chgrp -R gripfly /mnt/raid #prefix with sudo if your system doesn't have a normal root user! Check if it has changed (again, as root):
ls-l /mnt/raid The output should contain your username at least once. Btw, the previous command can be invoked prior to changing the group of /mnt/raid, in order to see the changes the command makes. If it doesn't work, you can revert the situation by replacing gripfly with the group name it had before and re-execute the command.
Pro-tip: use the arrow keys on the keyboard to scroll through previous commands on the cli (command line interface).
-
gripfly reacted to Dutch_Master in Raid array vanishes after reboot
That's good. You'll need write as well as read permissions to the /mnt/raid directory:
chmod -R +rwx /mnt/raid Having said that, it might be easier to re-assign the entire directory to your normal user. That comes with some security risks (although on a single-user system these are marginal) so try the chmod method first.
-
gripfly reacted to Dutch_Master in Raid array vanishes after reboot
Post the contents of the fstab file:
cat /etc/fstab As for the mail part, I haven't used it myself, but try switching the sender to Default.
-
gripfly reacted to Dutch_Master in Raid array vanishes after reboot
As root (or prefix with sudo)
mv /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.bak This moves your existing mdadm.conf file out of the way as a backup file (just plain text, as is usual in Linux) then reboot the machine. This should create a new mdadm.conf file, or nothing at all, and you should be able to create a new RAID in the web interface. If the 40MB RAID re-appears, just delete it completely by clicking on the array and then remove it with the corresponding button on the next page.
Note that if you want to assemble an array, you need to make sure each drive has a suitable file system on it. Technically it shouldn't have to, but in practice it's better to format a drive before inclusion in a RAID. Install the fdisk tool (or variants of it that can handle large partitions if you have large disks that require a GPT over traditional MBR) and format each disk as a single partition with ext4, JFS or XFS (choose one, don't mix!), then try to build a RAID with them.
-
gripfly reacted to Dutch_Master in Raid array vanishes after reboot
Your best option is to install a tool called Webmin. It does a lot of things, but for your case, it makes it fairly easy to get a RAID working, persistently. Add the Webmin repository to your sources.list file and use the package manager (Synaptic, aptitude) to install the tool. Once done, fire up your browser and connect to https://localhost:10000
During installation, Webmin will discover you've got mdadm installed already and make the RAID page available. It's under Hardware -> Linux RAID. Take it from there.
HTH!