Tesla Ye Nash

Hardware Requirements: 2 Ethernet Network Cards: 1 for WAN; 1 for LAN Optional Wireless Router for wifi Software Requirements: NIC Configuration Files sysctl Kernel Parameters Firewall Configuration dhcpd Server For the sake of clarity the two network cards will be called ifcfg-wan (WAN) and ifcfg-lan (LAN); make the necessary changes for your environment accordingly, e.g. eth0, ens1, enp0s77, etc., as I will not outline how to make naming changes for hardware devices.  The configuration files for the relevant network adapters/cards are located in /etc/sysconfig/network-scripts/ifcfg-wan and /etc/sysconfig/network-scripts/ifcfg-lan files . First, make sure all the interfaces are "down" and the ethernet cables are unplugged from both adapters.  Assuming you're not using NetworkManager this can be accomplished on the commandline with "ifdown wan" and/or "ifdown lan". Next, check the system's network activity for open por

I have a Lenovo ThinkPad laptop that occasionally displays error messages about "Hardware events/THERMAL EVENTS" during times of high CPU usage.  This is a scary set of messages in the journal logs that could prophecy a short life span of the CPU if neglected; at times I've suspected that it may have been the culprit of system crashes, though, I won't go into further details on that here. It's worth noting that the performance improves and error messages subside after one disassembles the laptop and cleans out the heat sink; maybe even properly applies a fresh coat of thermal compound on it.  This improvement, however, never lasts too long as the dust accumulates within the heatsink area again. I can recall reading anecdotal evidence of this problem from other ThinkPad owners on the Lenovo forums and other places when I first came across these scary messages on my system.  Those owners running Linux on their laptops offered explanations a

Since the advent of systemd the use of /etc/rc* startup-scripts has been discouraged and phased out. However, systemd still supports the use of certain local startup scripts for compatibility purposes. Nevertheless, to ensure full current- and future compatibility with systemd , administrators are encouraged to create own systemd service files or udev rules to run scripts during boot.  This post will briefly outline the use of a udev rule to assign a specific I/O scheduler to a specific HDD. NOTE To see an example using the phased-out rc-startup scripts, take a look at my previous post . Create a custom rules-file, e.g. 99-custom.rules , in the /etc/udev/rules.d/ directory with your editor of choice.  The following example will instruct udev to assign the deadline I/O scheduler to the /dev/sdb device: # vim /etc/udev/rules.d/99-custom.rules ACTION=="add|change", SUBSYSTEM=="block" , KERNEL=="sdb*", RUN+="/bin/sh -c 'echo dead

Since the advent of systemd the use of /etc/rc* startup-scripts has been discouraged and phased out. However, systemd still supports the use of certain local startup scripts for compatibility purposes. This post will briefly outline the use of the /etc/rc.local file to assign a specific I/O scheduler to a specific HDD. At the moment, I have an SSD drive (primary /dev/sda) and an "old-fashioned" HDD (/dev/sdb) in use on my RHEL7 system.  I'd like to be able to use the deadline I/O scheduler as the default and assign the cfq scheduler to the HDD device.  In RHEL7 the default I/O scheduler can change based on the selected tuned profile, which adds an additional layer of uncertainty if you're unaware of "tuned".  The default tuned profile is throughput-performance , which enables the deadline scheduler by default among other performance-related system settings.  However, if the default profile is changed to , e.g. virtual-host , the scheduler of choice

As with most things in Linux, there are an array of different tools and options available when dealing with the performance and power consumption of hardware components. Nevertheless, certain standard or even non-standard defaults always emerge, either distribution-specific or -agnostic. While a greater number of available tools provides greater control and more possible solutions, it also brings with it the possibility of greater potential for confusion and unclear incompatibilities. One such confusion arose when I noticed the inconsistency in my CPU frequency preference across reboots. I was used to using the cpupower utility from the kernel-utils package; however, options in the configuration file in /etc/sysconfig/cpupower had no effect on the system during the boot up process. It turns out that RHEL7 and, by extension, Centos EL7 use the tuned utility by default for performance tuning. As a result, according to a forum post in the Centos forum , ...that serv

The linux kernel adds the benefit of making firmware drivers available for a large number of widely-used hardware devices and components. This provides great convenience and ensures portability and sane defaults across the various OS distributions. The open-source nature of the Linux kernel, however, relies on the hardware manufacturers to make the firmware and/or drivers available to the Linux community; a process that can be frustratingly slow at times, depending on the hardware manufacturer. Furthermore, once the driver is included in the kernel, it falls on the various OS distributions to make the kernel or a patch to the kernel available for the users to install. The functionality of rarely-used hardware like a multimedia card reader (SD-card reader) are often overlooked by users until the day when they try to use the device. Usually, the kernel will load the necessary modules for the device to function properly during the boot-up process. Though, if an SD-card is not p

localtime Upon a successful login into the VM system, changing the Timezone to which the system’s time is configured can be accomplished by changing the /etc/localtime link . NOTE Since the implementation of systemd in RHEL7, changing the system’s default timezone manually is not persistent; as the /etc/localtime link gets recreated by systemd after a reboot, the user must use timedatectl to make the desired change persistent To change the default timezone to the timezone of Chicago, for example, execute the following as the root user: # cd /etc/ # ls -alh localtime /etc/localtime -> ../usr/share/zoneinfo/America/NewYork # unlink /etc/localtime # ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime /etc/localtime -> ../usr/share/zoneinfo/America/Chicago In the above example, we have changed the timezone from the previous value, pointing to the timezone to which “ NewYork ” belongs, to the timezone of Chicago. The systemd Method fo