• FidoGazette Vol 13 no 39 Page: 3

    From Janis Kracht@1:261/38 to All on Wed Oct 2 13:18:16 2019


    ================================================================
    A R T I C L E S
    ================================================================




    10 more essential Linux commands you need to know
    by Ken Hess (RedHat)

    You've mastered installation and the basics of filesystem
    navigation. Now you're ready to take your skills to the next
    level with 10 more essential Linux commands.

    Posted September 17, 2019
    by
    Ken Hess (Red Hat)

    10 more essential Linux commands you need to know

    Hopefully, you've read my 10 Basic Linux commands you need to
    know article, and now you're ready for the next higher rung on
    the sysadmin ladder. I n this article, I explore commands that
    every system administrator should know for troubleshooting,
    general housekeeping, and daily activities that you must
    perform.

    When you practice commands that can be harmful to a production
    system, have a virtual machine running somewhere that you can
    torture and restore should something go wrong. For some reason,
    people generally frown on having to repair or reinstall
    production systems because someone practiced a new command that
    went awry. Plus, it's cool to show up one day armed with new
    sysadmin skills to impress (school) your coworkers. Remember to
    say, "Watch this," to be sure they're paying attention before
    you hit the Enter key so it's more dramatic and awe-inspiring.

    NOTE: You don't have to be the root user to run any of these
    commands. To change system parameters or to edit system files,
    though, you will have to be root.

    Show who is logged in

    As a system administrator, it's your job to keep track of who
    logs into your systems, either through automation or when you're
    in the system yourself. A quick check can tell you a lot about
    what's going on at that point. For example, if you have a
    system whose performance is "in the red" and you're not sure why
    issue the who command to find out who is logged in. If you see
    a developer or group of developers, they might be testing a new
    application that is grabbing all the resources. Or you might
    have the occasional rogue user running a poorly constructed Nmap
    command.

    The who command tells you who is logged in, when they logged in,
    where they're logged in from, and even which type of connection
    they're using:

    $ who

    root tty1 2019-07-23 07:58
    khess pts/0 2019-07-23 07:59 (192.168.1.81)

    The ttyX logins are from the console and the pts/X ones are over
    the network from a computer via SSH. An acronym for Pseudo
    Terminal Slave, most sysadmins refer to the pts entries as
    pseudoterminals. The important thing is to note the difference
    between TTY (local console) and PTS (remote SSH) logins.

    Another reason to run who is if you're about to perform system
    maintenance. A quick check will tell you who you have to
    contact to advise them to log out of the system because your
    maintenance might include a reboot or other activity that will
    disrupt their work.

    echo a line of text

    Believe it or not, echo is one of the most powerful commands at
    your disposal. With this command, you can do things like create
    files, append to them, check return codes, and view system
    variables.

    To create a new file this command, use echo with some text, and
    then redirect the output to the file you want to create:

    $ echo "This is a test file" > test.txt

    You don't have to use quotes around the text, but I always doCÇöI
    worry that the text I redirect to the file won't look right if I
    don't. To be sure it's correct, cat the file:

    $ cat test.txt

    This is a test file

    To append some text on the next line, use the append redirect
    operator ( >> ):

    $ echo "This is how to add text to a file" >> test.txt

    $ cat test.txt

    This is a test file
    This is how to add text to a file

    Check the return code from the last command you ran with echo:

    $ echo $? 0

    A 0 response typically means success. You can also use echo to
    check your environment variables:

    $ echo $SHELL

    /bin/bash

    The echo man page gives you many more options and capabilities,
    such as how to use tabs, backspace, carriage returns, and more.

    Display the top Linux processes

    The top command does much more than simply display Linux
    processes, but it's a start. Run top at the command line to
    observe for yourself all the information that this command
    provides:

    top - 10:14:04 up 5 days, 48 min, 2 users, load average: 0.00, 0.00, 0.02
    Tasks: 233 total, 1 running, 232 sleeping, 0 stopped, 0 zombie
    %Cpu(s): 5.9 us, 5.9 sy, 0.0 ni, 88.2 id, 0.0 wa, 0.0 hi, 0.0 si,
    0.0
    MiB Mem : 1829.4 total, 191.2 free, 1066.0 used, 572.2 buff/cache
    MiB Swap: 0.0 total, 0.0 free, 0.0 used. 538.7 avail Mem

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    1651 khess 20 0 64016 4936 4056 R 11.8 0.3 0:00.02 top
    1 root 20 0 179492 12076 6804 S 0.0 0.6 0:40.77 systemd
    2 root 20 0 0 0 0 S 0.0 0.0 0:00.17 kthreadd
    3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
    4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_

    The listing above shows the first few lines from my Red Hat 8.0
    server's top display. This command runs continuously, so to
    exit, type q. This command is named top in the first place
    because it provides a real-time display of the top processes by
    CPU and memory usage. To see an exhaustive explanation of the
    top command, refer to the man page.

    Other than q, the most beneficial key command for me is k, which
    prompts a process ID (PID) to kill (terminate). As a system
    administrator, it is your job to protect system health for the
    general user population of that system. In other words, killing
    processes to release resources is one of the things you do,
    within reason, of course. It's career-limiting to kill
    processes in a haphazard fashion, but it's something that has to
    be done from time to timeCÇökilling processesCÇönot killing them
    haphazardly.

    The top command gives you a real-time snapshot of system
    performance. Typically, you run top when a performance problem
    is reported. When a system is idle, running top isn't exciting
    and often results in showing top as the most resource-consuming
    process on the system. Don't be alarmed by this, but do realize
    that it's possible.

    Use top as much as you like, but realize that its information is
    not necessarily indicative of overall system performance. It is
    a snapshot and not a measure of long-term activity.

    kill a process

    Although I wrote in the section above that it's your job to
    sometimes kill processes, exercise caution when doing so.
    There's a good chance that abruptly ending a process will cause
    data corruption, data loss, and even job loss for you if you
    haven't cleared such actions through the proper channels.

    The two most often used signals or options for the kill command
    are -15 and -9. Issuing a kill -15 <PID> is known as a soft, or
    polite kill. The -15 (also known as SIGTERM) signal kills the
    process but allows it to finish any pending processing:

    $ kill -15 <PID>

    The -9 signal ( SIGKILL ) immediately terminates the program
    with no regard for current processing. The -9 signal kills it.
    End of story. End of process:

    $ kill -9 <PID>

    There are two specific times to use the -9 signal. The first is
    when you have a runaway process that can't be killed with the
    -15 signal, and the second is when you need to free system
    resources immediately without regard for data loss or
    corruption. This second scenario is rare, but it does happen.
    In that situation, the only other option might be to reboot the
    system. Even after killing the process, you might have to
    reboot anywayCÇökilling certain processes can leave the system in
    an unstable state.

    The takeaway here is to use kill sparingly and only with permission.

    Closely associated with the kill command is the killall command.
    If you have a process such as the Chrome web browser that can
    consume more than its share of resources, you can issue the
    killall <processname> command to rid the system of all its
    spawned processes. The killall command doesn't require you to
    know the PID, nor do you have to kill each individual process.
    Doing so can become way too tedious, and system administrators
    haven't the patience for such things.

    $ killall chrome

    This command terminates all instances of Chrome owned by this
    user. You can issue the same command as root, but read the
    previous dialog about exercising caution when doing so, because
    issuing such a command as root terminates the program for
    everyone on the system.

    Note: If your system doesn't have the killall command available,
    then you'll have to add it by installing the psmisc package as
    shown below.

    $ sudo yum -y install psmisc

    I know, we haven't discussed the yum or dnf commands yet. Take
    this one as a "just do it" lesson at this point.

    View files more or less

    If you've used commands such as ps, you know that file listings
    can be long, and a lot of the information flows right off the
    screen. Sure, you can page up or scroll, but it's not very
    efficient.

    The commands more and less limit the amount of data you see to
    one "page." As with many things Linux-related, users are in two
    camps: the more camp and the less camp. I'm in the more camp.
    I never use less. And, no, less isn't more. Even the less man
    page reads, "The opposite of more."

    From a usage standpoint, these two commands are similar.
    However, the differences surface when interacting with these
    commands. It's impossible to show effectively in a static
    article but less has a few more navigation options than more.
    The more command's options are:

    Advance one line using the Enter key.
    Advance a full page using the Spacebar .
    Quit by entering q.

    You cannot move backward using more. Less , being more
    Wonkavator-esque , allows you to move backward, search for
    strings, and much more. Use the man pages for more and less to
    decide which of these commands is right for you.

    To make things even more complex, there are two ways to use more
    and less. You can pipe (|) output to more and less or you can
    use these commands to operate directly on files. Here are some
    examples (without their output):

    $ more /etc/passwd

    $ cat /etc/passwd | more

    $ ps -ef | more

    $ less /etc/passwd

    $ cat /etc/passwd | less

    $ ps -ef | less

    Update user passwd authentication tokens

    Standard users use the passwd command to change their passwords.
    It's quick and simple to do. Issue the passwd command and
    you're prompted to change your password:

    $ passwd

    Changing password for user khess.
    Current password:
    New password:
    Retype new password:
    passwd: all authentication tokens updated successfully.

    When changing your password, you'll notice that the system does
    not respond with any dots, stars, or even blank spaces. This
    feature is far more secure in situations where someone is
    shoulder surfing during a password change. There is also no
    option for showing the password. Again, very secure.

    There are additional passwd command options for the root user.
    For example, if you issue the following command as yourself,
    check your system's response:

    $ passwd -S

    Only root can do that.

    If the root user issues this command with a username, the
    command displays user information:

    $ sudo passwd -S khess

    khess PS 2019-07-29 0 99999 7 -1 (Password set, SHA512 crypt.)

    The real power for system administrators is being able to set a
    user's password without knowing the current one:

    $ sudo passwd khess

    New password:
    Retype new password:
    passwd: all authentication tokens updated successfully.

    As root, you can optionally lock and unlock user accounts:

    $ sudo passwd -l john

    Locking password for user john.
    passwd: Success

    $ sudo passwd -u john

    Unlocking password for user john.
    passwd: Success

    Use passwd responsibly. And when offboarding a user, you should
    lock the account rather than deleting it: The user might have
    important data saved in their home directory, or have a process
    running that requires the account to be functional. Locking is
    good enough to prevent further interactive logins, and will also
    inform you about any automated tasks that require a password to
    perform. ifconfig a network interface

    There are tasks that as a sysadmin you don't do every day, but
    when you do them you need a power command like ifconfig. I
    classify this command in the power category because it does many
    things, but with simple syntax.

    Note: While a user can look at network interface configurations
    and settings with, you must be root to make changes.

    $ ifconfig
    enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    inet 192.168.1.96 netmask 255.255.255.0 broadcast 192.168.1.255
    inet6 2600:1702:a40:88b0:581f:ea48:4e1a:6711 prefixlen 64 scopeid 0
    inet6 fe80::3d1d:ee56:9c1c:33b prefixlen 64 scopeid 0x20<link>
    ether 08:00:27:a7:47:25 txqueuelen 1000 (Ethernet)
    RX packets 1153803 bytes 230635486 (219.9 MiB)
    RX errors 0 dropped 0 overruns 0 frame 0
    TX packets 78485 bytes 8389458 (8.0 MiB)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

    lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
    inet 127.0.0.1 netmask 255.0.0.0
    inet6 ::1 prefixlen 128 scopeid 0x10<host>
    loop txqueuelen 1000 (Local Loopback)
    RX packets 48 bytes 5616 (5.4 KiB)
    RX errors 0 dropped 0 overruns 0 frame 0
    TX packets 48 bytes 5616 (5.4 KiB)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

    virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
    inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
    ether 52:54:00:7a:a9:b2 txqueuelen 1000 (Ethernet)
    RX packets 0 bytes 0 (0.0 B)
    RX errors 0 dropped 0 overruns 0 frame 0
    TX packets 0 bytes 0 (0.0 B)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

    You can also use ifconfig to assign IP addresses to interfaces,
    change an interface's IP addresses, take an interface offline,
    bring one online, and more. grep a pattern

    Use the grep utility to search for a particular pattern inside a
    file or group of files. For example, say that you have a file
    in your home directory that contains the IP address of a remote
    system that you worked on a few months ago, but you can't recall
    the exact address. You know it was something like
    192.168.10.???. The problem is that you have 50 files in your
    home directory and it would take hours to search through them
    all by hand.

    Well, fret no more, grep is here to help. In this example, you
    can grep for the 192.168.10.pattern in your home directory:

    $ grep 192.168.10. *

    grep: data: Is a directory
    grep: docs: Is a directory
    grep: documents: Is a directory
    grep: form: Is a directory
    grep: forms: Is a directory

    Notice that several of the entries state that you're attempting
    to look into files that are directories, and that your search
    came up negative for a file containing the IP address. Use the
    recursive option ( -R ) to search subdirectories:

    $ grep -R 192.168.10. *

    documents/systems_list.txt: 192.168.10.45 pumba

    Here, your search was successful. The grep command returned the
    entire line that matches your pattern.

    When system administrators mention grep or "grepping" something,
    they usually refer to piping in the same sentence, as in "Pipe
    it to grep." You don't always need to pipe to grep as you can
    see from the example above. But, piping to grep works in a
    similar way. To search for systemd in your process list:

    $ ps -ef |grep systemd
    root 1 0 0 Aug07 ? 00:00:40 /usr/lib/systemd/systemd --sw
    root 476 1 0 Aug07 ? 00:00:11 /usr/lib/systemd/systemd-jour
    root 505 1 0 Aug07 ? 00:00:02 /usr/lib/systemd/systemd-udev
    root 632 1 0 Aug07 ? 00:00:02 /usr/lib/systemd/systemd-mach
    dbus 653 1 0 Aug07 ? 00:01:45 /usr/bin/dbus-daemon --system
    root 712 1 0 Aug07 ? 00:00:07 /usr/lib/systemd/systemd-logi
    gdm 1209 1 0 Aug07 ? 00:00:02 /usr/lib/systemd/systemd --us
    gdm 1301 1209 0 Aug07 ? 00:00:00 /usr/bin/dbus-daemon --sessio
    khess 2423 29513 0 10:25 pts/1 00:00:00 grep --color=auto systemd
    khess 8088 1 0 Aug07 ? 00:00:03 /usr/lib/systemd/systemd --us
    khess 8113 8088 0 Aug07 ? 00:00:00 /usr/bin/dbus-daemon --sessio

    As you can see, piping to grep is the only way you can find all
    instances of systemd from the process list. Note the first
    entry with my username on it. That is my grep command searching
    for systemd. If you don't want to see that entry, use the -v
    option to exclude the grep command itself from your results:

    $ ps -ef | grep systemd | grep -v grep

    The other grep option that I find helpful is the ignore case
    option( -i ):

    $ grep -iR bob *

    This command searches recursively through all files for the
    string bob , regardless of case, which could match all of the
    following: Bob, Spongebob, bilbobaggins, and BObrice.

    Grep is very useful and can be used on text files, and in
    conjunction with other commands via piping. You can also grep
    for complex patterns using regular expressions (regex) but that
    is a topic for other articles. Scan and process patterns with
    awk

    I feel like awk is one of those tools that few people use
    because they don't understand the full power and possibilities
    of this little dynamo. I will jump right in with some examples.
    Say that I want a list of all processes that are
    systemd-related, but I only want the PIDs, not all of the other
    information that you get with ps:

    $ ps -ef | grep systemd | grep -v grep | awk '{print $2}'

    1
    471
    608
    631
    7449
    7494
    32681

    To explain the command above:
    I ran a ps, grepped for systemd, removed my own grep command,
    and then piped the output to awk and printed the second column.
    It is the second column because by default awk uses a space as a
    field separator. The formal awk part of the command would look
    like this: awk -F " " '{print $2}', where the -F option defines
    the field separator.
    For comma-separated values, you'd use:
    awk F "," '{print $2}'.

    If you have a text file ( test.txt) containing the following:

    one,two,three,four,five
    1,2,3,4,5
    6,7,8,9,10
    a,b,c,d,e

    And you run awk against that file to extract the third column of
    data, it displays the following:

    $ cat test.txt | awk -F "," '{print $3}'

    three
    3
    8
    c

    I think you can see what's going on with awk here. It's handy
    for automation scripting as you can probably tell from these
    examples. You can extract data and operate on it dynamically
    with awk.

    Edit text with vi

    The vi (visual) text editor was a clever developer's (Bill Joy)
    answer to updating the old line editor ex, which Bill Joy also
    wrote. This program 40+ years later is still the most used
    Linux command line text editor.

    The vi editor is small, with the latest incarnation ( vim aka vi
    improved) weighing at just over 3MB in size. These days vi is
    often a symbolic link to vim (in RHEL 8, for example). Its
    enhancements include multi-level undo, multiple windows and
    buffers, syntax highlighting, command line editing, file name
    completion, online help, and visual selection. Open vim and use
    the following command for a summary of the differences between
    vim and vi :

    :help vi_diff.txt

    vi has so many options and features that I'm only mentioning it
    as one of the commands you need to know in this article. Please
    refer to my vi : An introduction article for a more extensive
    look at vi.

    Wrapping up

    Surprisingly, out of more than 200 possible Linux commands, most
    system administrators only use about two dozen on a regular
    basis. If you know those, system administration becomes easier
    and far more elegant. Struggling with commands and syntax makes
    the job harder. Learn these popular and highly-used commands
    and you'll have the power to make a difference in your
    environment.



    FIDOGAZETTE Vol 13 No 39 Page 3 October 02, 2019


    -----------------------------------------------------------------

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: Prism bbs (1:261/38)
  • From Richard Falken@1:103/705 to Janis Kracht on Thu Oct 3 07:32:58 2019
    Re: FidoGazette Vol 13 no 39 Page: 3
    By: Janis Kracht to All on Wed Oct 02 2019 01:13 pm

    Very nice article. I'd suspect that a lof of people here is familiar with basic Linux commands but it is good to have a refresher.

    I also feel that pgrep and pkill were glaring omissions. I love pkill. The thrill, the danger!
    --- SBBSecho 3.10-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Janis Kracht@1:261/38 to Richard Falken on Sat Oct 5 20:19:04 2019
    Hi Richard,

    Very nice article. I'd suspect that a lof of people here is familiar with basi
    Linux commands but it is good to have a refresher.

    After the antibiotic I had to take destroyed my brain that week, I for sure was glad to find that article <grin> I use a bash script I wrote ages ago to 'print' the fidogazette to the echo, create the archive, make the reports in the 'zine, and hatch it out.. it all looked like greek to me :)

    I also feel that pgrep and pkill were glaring omissions. I love pkill. The thrill, the danger!

    Lol..

    Take care,
    Janis

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: Prism bbs (1:261/38)
  • From Sean Dennis@1:18/200 to Janis Kracht on Sat Oct 5 23:39:38 2019
    Hi Janis,

    <grin> I use a bash script I wrote ages ago to
    'print' the fidogazette to the echo, create the
    archive, make the reports in
    the 'zine, and hatch it out.. it all looked like greek to me :)

    When I switched my BBS over to ArcaOS from Slackware, I rewrote a lot of my scripts from bash over to REXX. With Arca, however, a lot of your basic core programs have been ported over, such as sed and awk. Many of the little scripts I wrote, such as one that grabs a weekly newsletter from an amateur radio website and converts it to CP437-based text, were basically a direct port.

    Now the script I wrote that runs MakeNL, creates the nodelist and infopack for Micronet, copies the nodelist over for my nodelist compiler, and runs NEF to hatch and announce the files as well as run cURL to upload the two archives to my website was ported directly to REXX.

    I have a script that scrapes the text-based local forecast for my area from my local NWS's website, converts it to CP437, and posts it hourly as a text bulletin to my BBS. I also wrote one that grabs the Telnet BBS Guide monthly list and hatches it out in Micronet.

    There is only one that I cannot port unfortunately and that is because "expect", part of the Tcl/Tk toolkit, hasn't been ported to OS/2-Arca. I am trying to find a workalike but so far I don't see one. I did add Pete Norloff's entire OS2BBS filebase, about 11 GB worth of files or around 22,000 files, into my BBS. It was pretty easy since Pete ran Maximus 2.02 and I run Maximus/2 v3.01. Just copied the file areas onto my hard drive, set them up in FILEAREA.CTL then ran "fbp -a". :D

    If you want, I could share some of these smaller scripts I've written. They're nothing fancy or difficult though the one for the Micronet weekly maintenance is a bit hectic (and I am hesitant to share that one).

    I have found that my curiosity about writing scripts has helped me immensely in many things, not only just BBSing, but working in IT in general. It's nice to know how to automate some rather boring and mindless tasks :)

    Later,
    Sean

    P.S. I use "links" heavily in scraping websites. Its built-in capacity to properly "dump" HTML to text as well as converting the text to CP437 is a huge help. "Lynx" does the same and it will automatically create footnotes with the full dumps of all URLs listed on a page. I don't need that for now so I use "links".


    --- Maximus/2 3.01
    * Origin: Outpost BBS * bbs.outpostbbs.net:2304 (1:18/200)
  • From Oliver Thuns@2:280/464.47 to Sean Dennis on Sun Oct 6 08:14:10 2019
    When I switched my BBS over to ArcaOS from Slackware, I rewrote a lot of
    my
    scripts from bash over to REXX.

    --- Maximus/2 3.01

    Did you also run Maximus on Slackware? I was unable to compile it.


    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: * (2:280/464.47)
  • From Sean Dennis@1:18/200 to Oliver Thuns on Sun Oct 6 16:01:50 2019
    Hello Oliver.

    06 Oct 19 08:16, you wrote to me:

    Did you also run Maximus on Slackware? I was unable to compile it.

    I never tried. Maximus was originally developed specifically for OS/2 and plays on the operating system's strengths. The other versions are really lesser versions so I've no interest in that.

    I do have MBSE setup on Slackware however that system is down indefinitely at this time.

    Later,
    Sean

    --- GoldED/2 3.0.1
    * Origin: Outpost BBS * bbs.outpostbbs.net:2304 (1:18/200)
  • From August Abolins@2:221/1.58 to Sean Dennis on Sun Oct 6 16:55:00 2019
    Hello Sean!

    ** 05.10.19 - 23:39, Sean Dennis wrote to Janis Kracht:

    Hi Janis,

    <grin> I use a bash script I wrote ages ago to
    'print' the fidogazette to the echo, create the
    archive, make the reports in
    the 'zine, and hatch it out.. it all looked like greek to me :)

    When I switched my BBS over to ArcaOS from Slackware, I rewrote a lot of
    my scripts from bash over to REXX..

    I have found that my curiosity about writing scripts has helped me
    immensely in many things, not only just BBSing, but working in IT in
    general. It's nice to know how to automate some rather boring and
    mindless tasks :)

    That is probably one of the most common reasons why operating a bbs has attracted many of us (myself included) into the hobby. Using the tools to build automated processes, watching it all operate and tracking down bugs, served us as the puzzle-solvers that we ultimatley are.


    ../|ug

    --- OpenXP 5.0.40
    * Origin: /|ug's Point, Ont. CANADA (2:221/1.58)