102-500: LPI Level 1 Certification Video Training Course
102-500: LPI Level 1 Certification Video Training Course includes 126 Lectures which proven in-depth knowledge on all key concepts of the exam. Pass your exam easily and learn everything you need with our 102-500: LPI Level 1 Certification Training Video Course.
Curriculum for LPI 102-500 Certification Video Training Course
102-500: LPI Level 1 Certification Video Training Course Info:
The Complete Course from ExamCollection industry leading experts to help you prepare and provides the full 360 solution for self prep including 102-500: LPI Level 1 Certification Video Training Course, Practice Test Questions and Answers, Study Guide & Exam Dumps.
In Linux systems, there are so-called run levels. A run level is a state in which the computer currently runs Linux controls.via the run level, which services are started automatically and which are not. By default, there are seven different runlevels ranging from zero to six. Let's take a closer look at the run levels. As I said, we have seven different run levels. From run level zero to run level six, the standard run level for desktop systems is level five. In run level five, various users can log into the system. There are, of course, network services, so I can serve the Internet, et cetera. and a graphical user interface is also available. In this run, level five, I am currently running my system. Let's take a look at run level zero. Run level zero means the system is switched off. When we tell the system to switch to run level zero, the system understands that it needs to shut down. Run Level One is also called Run Level S. In this case, S stands for single-user mode. Single user mode means that no matter how many users are stored in the system, none of them will be able to log into the system. Only root can log in to the system. Root, in case it has not yet become clear, is the administrator of the system. Additionally, no network services are available; however, a Sonos Internet connection can be established. A graphical user interface is also not available. Run Level One is the emergency mode, so to speak. Let's say that for some reason we realised that someone had hacked the server. In this case, it is advisable to switch to runlevel one as soon as possible, provided that you have the opportunity to work directly on the server as root. This ensures that an attacker who usually accesses the server via the Internet is locked out directly. Because network services are deactivated in route level 1, and multi-user is also deactivated, only root can log in. Then there is Run Level 2. In contrast to Run Level 1, multiple users are allowed here. This means that other users besides Root can log in, but there are still no network services and no graphical user interface. Level three allows multiuser login, and network services are also available. Run level three is usually the standard runlevel for server systems, and because of that, there is no graphical user interface. Run Level Four is usually not used. Run level five; we talked about that at the beginning of the lesson. And run number six means that the system will be restarted. The states in this table have become established. However, there are differences from distribution to distribution, but run level zero and run level six are always the same. We have now discussed what the individual run levels do. Let's take a look at the whole thing in practice. Let me switch to my terminal. Okay, let's take a look at the Run Level main page. Print the previous and current run levels for this V. So when you execute the run level command, the system tells us, on the one hand, which run level you are in and which run level you were in before. Let's run the command once run level.At this point, we can see that we are in run level five at the moment, the run level in which there are no restrictions. So we have multiuser login network services and a graphical interface. N on the left shows us that the system has not yet changed to any other run level. If there were two, for example, we would know that the system was at run level two before run level five. We can change the run level at this point. For this, we use the init command. So I will type in init three because I would suggest trying run three, and now I am asking for the password. Of course. Yeah. Without a graphical interface, we can see that we have an account masking as expected. Why? Run level three is the standard server run level. As a rule, no graphical user interface is used on servers. The fact that we can log in also proves that the multi-user functionality works. So I have to type my name first and then the password, and now I'm logged in. Let's use the Run Level command again. And we can see that we are currently in run level three and that we were previously in run level five. We can also use the run-level command to shut down or restart the system. We remember that run level six means that the system will be restarted. Run level zero means that the system is switched off. By the way, you can also use the tell init command instead of the init command. We could have used "tell initthree" instead of "init three." The result would have been absolutely the same. Make sure to remember this for the exam, because both commands are often queried. If I now enter "tell it six," we switch to run level six. And running level six means that the system will be restarted. So I'm waiting for the reboot. So the system has started up again, and I can log in again. And, of course, we can see that we've returned to renderable five. because we can see a graphical user interface. We automatically switched from level three to level five. After we started, we restarted the system with "tell init six." How does the system know that? If I now use init 6 or tell init 6, as in this case, at which run level the system must start after the restart in a SysV init system, this is specified in the Etsy initub file. We talked about this in detail in the ZSV initial lesson, which is why I won't show it again here. If you don't know it anymore, just look at the lesson again. The run levels are a holdover from the SIS V init system with System D systems. It works a little differently here. There are the so-called boot targets. That's what the next video is about.
In System D systems, the run levels are no longer called run levels but rather boot targets. Here we have a list of the boottargets, in which I compare the current boottargets with the earlier run levels. We have one level zero here. Run level zero corresponds to the power-off target. Run level one corresponds to the rescue target. Run levels two, three, and four, which correspond to the multi-user target. Run level five corresponds to the graphical target, and run level six corresponds to the reboot target. Even if we are in system D, the original run levels are still functional. So I can still switch to the corresponding runlevel with init 2 or with init 3. I showed that in the last video. Here I used my current Ubuntu, which is a System D system. That means the old commands still work, but actually it is desired that we solve the whole thing with the boot targets. So let me switch to my terminal. We've arrived at run level five, or the graphical target. If we now, for example, want to switch to the multiuser target, we have to use the systemctl isolate command. We still know systemctl from the system D lesson in which we started, stopped, or queried programmes with systemctl with system D isolate, so we can change the boot targets. For example, we change the multiuser target. For this, we use the following command: sudo, of course, systemctl isolate, and then multiuser target. so I have the password window here. Yeah, now we have a login window. I log in with my name and password, and now we are in the multi-user target. If we use the old command "run level," then we see that this is run level three. We are now at run level three. Okay, we can now shut down and restart the system as well. This would still work with init six or ten init six, but we are using the boot targets in this case. And that would be the following command: zoodo systemctl isolate reboot dottarget password, and the system reboots. And now we are back at our standard target. What is actually our standard target? We can get this out with the following command: systemctl get default, and we see that our standard target is the graphical target. If we now, for example, want to turn our Linux desktop system into a Linux server, we should select the multi-user target as the standard target. And this is done with the following command: system50 l set default multiuser target. We have to remember to display the standard boot target, so we select the command systemctl get default. If we want to change the default boottarget, we issue the command systemctl set default, followed by the appropriate boot target. Of course, in the output you can see that a link has been created from the default target to the multi-user target. So the system says my default target, which I always want to start with if nothing else is specified, is now also the multiuser target. So you can also see how the command works. We can check that again with systemctl get default, and now our standard target is the multiuser target. If we restart the system now, it should now start in multiuser mode. Let's try it out: pseudo systemctl isolate reboot target, we wait a few seconds for the reboot, and we see that the system starts without a graphical user interface, just like we configured it before. Unfortunately, there is no system CTL command that shows us the current boot target. At least I don't know any and haven't found any. But we can help ourselves with the run-level command. According to the table, run number three is the multiuser target. So everything works exactly as we want it. Let's switch back to the graphical target now. Isolate graphical dot target with pseudosystemctl At this point, I'd like to change my standard target again, so I'll use the pseudo-system CTL set default graphical target and see if it works. Systemctl get default and it workseverything as it should be. At this point, we may briefly cover the last topic or the ultimate topic of this lesson. We learned that there are several different ways to shut down or restart a Linux computer. Shut down, for example, with init zero or telinit zero, or isolate the poweroff target with system CTL. In the case of a restart, we can use init 6, tell init 6, or systemctl isolatereboot target. But there is also another command that we can use for this, and that is the shutdown command. We take a look at the main pages—shutdown, hold power off, or reboot the machine. The shutdown command is used as follows. first, of course, the shutdown command, followed by an option and a time. The command does not work without any time specification. Let's test the following command as an example: This command means that the shutdown command is used with the R. Option R stands for reboot. The time plus ten means that the reboot should be carried out in ten minutes. So we see here a shutdown scheduled for Thursday at 949, and yeah, that's exactly in ten minutes. You can cancel or abort the entire process by using shut down and option C. Shut down C. And if I now want to specify that the computer is restarted immediately and not in ten minutes, then I can do it as follows shutdown Rnow or the other possibility shut down R plus zero. In both cases, the restart takes place immediately. There is no difference here, only the spelling. Instead of shutdown R for reboot, we can use shutdown with the option H. H stands for "hold" and means that the system will be shut down and switched off immediately. Again, we have to specify a time with shutdownhalt plus 20 I will not execute it here. Alternatively, we can also specify when we can use this. We see a shutdown scheduled for 23:45; let me cancel that. I don't think we have to go through that again now. But of course you are welcome to test it all on your own computer, even if it is not explicitly stated in the Epic commands. Let's look at another command that can be used to restart the system. This would be the reboot command. Let's take a look at the main page of Men Reboot. We see that we can still use these three commands here, alt power off," reboot hold," power off," to do the same thing. The systems are shut down and turned off. A reboot ensures that the computer restarts. Of course, it would be a bit inconvenient if you just restarted a server as root. Of course, in some situations there is no other way, and if there are any problems, it can happen that a server has to be restarted. If you have enough lead time, users locked onto the server can be informed in advance of the upcoming restart. With the wall command, we take a look at the main page for all users. All users refer to those who are directly connected to the server. Not the users who may be on any Windows computer in the same network and use a server application. They do not receive this message. Only the users who are locked in directly to the Linux server The syntax is very simple for a wall test Yeah, we can't check it now, but this is how it works You can also combine the wall command with the shutdown command. We return to the shutdown main page, where we can see shutdown options, time, and wall. So we can say, for example, that the server was shutdown at midnight, but the caution server will restart at midnight; the server will now be restarted at midnight, and all users logged onto the server will receive the corresponding message. Okay, that was the first complete topic. Topic 101: System Architecture. The second section deals with Linux installation and package management. You.
This lesson starts out with the main Linux directories. if you have not yet had any experience with Linux. You can perhaps compare this a little with the drive letters in Windows. The hard drive or partition there is usually called C. A second hard drive or partition is most likely D. But the CDROM drive can also be a D. Let's assume the Windows hard drive is C. If you now click on C in Windows Explorer, you will find yourself at the top level of the hard drive, directly on C, without being in any directory. If we compare this with Linux, in this case there is no C, but there is the so-called root or the root directory. Root is also expressed with a slash I'll switch to root cityroot, and now we are inside route, and here too, at this point, we can see that we are currently in root. Root is the top part of the directory tree in a Linux system. All other directories are located at root, just as with C under Windows. It can be a bit confusing at first because there is a difference between the topmost point of the directory tree and its root. As a user, the administrator user is called root in Linux. Additionally, there is also the root directory here. You have to pay close attention to what is meant in the relevant questions later in the exam. We can see which subdirectories are present if we CD into root, as I just did. We can see all the subdirectories here. We have a few links here, and we have a file here. Almost all subdirectories are standard in Linux, and they serve a specific purpose. What these directories stand for and what they contain is defined in the so-called filesystem hierarchy standard, or FHS for short. FHS has defined a guideline for how the file structure should look in Unix-like operating systems. The reason for this is that Linux administrators should find their way around all distributions. This also ensures that an application can not only run in a certain distribution but also in all others. For software developers, it is, of course, much easier if the directory structure is the same on all Linux systems. We already got to know the directory procedure in the first few lessons. We learned about proc and about death. What other directors' directories are there? We will take a look at these one by one. We have here the bin directory binbin, which contains basic system commands that administrators and users can use and execute. For example, consider message D message.We have already sent a D message together. We remember Dmessage reads the kernel ring buffer, and this command can be used by both root and standard users and is therefore correctly located in the bin directory. Here we can find the message command. Okay, maybe not in the correct order now, but since it fits so nicely, let's look at the spin directory. Next, CD also contains system commands, but these are the so-called "important" commands that only root or users with root rights may execute. An example here would be in It, which we already looked at in the lesson on the run levels. Again, to repeat, with the init command we can change the run level, shut down, or restart the server. Of course, only root users should have this authorization. It would be fatal if every user were able to shut down or restart a server. So the init command in thespin directory is just right. Next, we have the boot directory here: CD boot. This directory contains all files that are required when the system is booted. So the static part of the kernel will also store it here. The initial RAM disc can also be found in the boot directory here and here. We also have a reference to the bootloader, grub. And we have a few configuration files wealready got to know depth to repeat. This is where the system device files are located. Next we have a very important directory called the Etsy directory, etc. Or Etsy. You can call it Etsy. The name originally comes from, etc. So for everything else that had no place anywhere else, In the meantime, however, it has established itself as a configuration directory. Etsy and their respective sub-directories contain all kinds of configuration files. No matter which programme you want to configure, the corresponding configuration files can almost always be found on Etsy. Do you remember the "file edits" tab, for example, that we talked about in the Sysit lesson? You will find it here in the Etsy directory. So if you ever look for a configuration for ProgramX, you are guaranteed to find it on Etsy. Next, we have the home directory. The directory home contains a subdirectory for each user who has storage on the system. In my case, that's just one user in this subfolder, which usually has the same name as the user. This user can store his own data, for example, downloads or documents, tables, or anything else. The respective user usually has full rights to his personal home drive, so he can of course create files, delete them, and so on. Of course, no user has access to the home directory of another user. Next, we have the lib directory. The directory lib contains so-called dynamic-label libraries, which are required for most programmes located in Bin or SBIN. On Windows systems, every programme brings its own libraries with it. It can happen that one of the same libraries is available a dozen times, always in the respective subdirectory of the corresponding program. On Linux systems, the corresponding library is only installed once and is then located in the lib directory. The kernel modules are also located here. We talked about this in one of the first lessons modules, and here are the two kernel versions and the kernel modules. In addition to Lib, the lib 64 directory is frequently present. In this case, we have a Lip 32 directory as well. Often, there are separate libraries for certain processor architectures and certain programs. In this case, for 64-bit systems. The directory lost and found does not belong to the file system hierarchy standard, which is why we will not go into it further. The next directory is media. All types of removable storage media are mounted or attached as media in Linux. A device, for example a USB stick or a USB hard drive, can be attached to the file system. That is to say, made available, so to speak, and you have to tell the system where it can find the device in the future. There will be a separate lesson on this later, which is why this must be sufficient as a short explanation. Here the directory MNT, short for "mount," is also the entry point for foreign file systems of all kinds. Next, we have the opt directory. This directory contains optional packages. Most of the programmes installed here are third-party programmes that are not part of our own package sources. The binary files of the corresponding third-party software are usually located in the programme name bin. I've only installed the VirtualBox guest editions here. If I look inside, I see that we can also find a bin subfolder here. We have already talked extensively about props. Next we have the root directory. Root is just the home directory of the user root. We see that we do not have permission to enter this directory. That's how it should be. Of course, nobody is allowed to enter another user's home directory. Next, we have the run directory. Run is a relatively new directory. Until 2011, it didn't exist at all. In the past, the directory VR run was swapped out for run. There was occasionally the issue that VAR was required to boot but was not yet available. This should be fixed by completely swapping out the run directory. Various data from running processes is located within run. We do not have to know exactly what kind of data this is for the exam. Next we have the Snap directory. Snap is also not part of the hierarchy standard. This directory contains files and subdirectories of installed Snap packages. Snap is a package format that can also be installed. Then we have the SRV directory. SRV should mean "services" and not "service," as is often assumed. The directory structure is not precisely specified in the case of SRV, and it should contain data that is passed on by other services. The directory does exist on Ubuntu, but it is usually an empty SRP. Yes, it's completely empty. We next have the this. We already talked about this. We have the "temp" directory. Temp contains temporary files for programs, and in most Linux distributions the directory is emptied on shutdown. Many system administrators also use TEMP to download software packages there or cache files. Many programmes also use TEMP to store temporary files. We now have the directory userUSR, which actually comes from user. In this case, the individual user directorieswere also located here when the homedirectory did not yet exist. Today's user contains most of the systemtools, some libraries, and installed programs. User is a very important directory, so we have to take a look at a few subdirectories. Here we have here for example the subdirectory pleasenotice we are now in user bin and notonly in bin, but in user bin. The application programmes are located here. For example, the desktop programmes or those that were installed afterwards via package management If we use the package management, which we will talk about in detail later, and install the Firefox browser, for example, then we will most likely find the appropriate programme here. Then we have the lib directory here CD lib. This contains the libraries for the corresponding programme from the user's bin. In other words, the lipdirectory, which can be found directly under root. We also have the directory "User local." Here is exactly the same directory structure as in User. You can compare it here. Here we are in the user's bin. Games include "flip," and here we are in user local. Bin games include nearly identical programmes that are installed in user local independently of the package manager. So if you, for example, downloaded a file from the Internet and manually installed it as a result, the binary files for the programmes are then located in the user's local PIN. Then we have the user-shared directory user share.Static data is saved here that is not changed in user sharing. We find, for example, the man pages that we have used before. In UserShare Doc, we find various documents for everything that Linux contains. Yeah, and finally, we have the VAR directory in VAR. In contrast to user share, there are variables in subdirectories that change frequently and are almost always in motion. Web pages are also often stored in VAR. When a web server is installed, these are frequently stored in varw. All system locks are stored in VA Lock. And here we see various log files. In VAR, we also have temperature. Temp files are cached until they are required during booting. Also, there are temporary files that should be kept after a reboot, which is why it is quite possible that this directory gets quite full with VAR run, seeing that it is just a reference to run. We have already talked about running before. Okay, those were all the directories and their tasks. I recommend that you study all this because there are guaranteed to be some questions to be expected in the exam.
Student Feedback
Download Free LPI 102-500 Practice Test Questions, LPI 102-500 Exam Dumps
File | Votes | Size | Last Comment |
---|---|---|---|
LPI.questionpaper.102-500.v2024-08-31.by.sophie.66q.vce | 1 | 275.1 KB | |
LPI.Testking.102-500.v2020-02-23.by.Oscar.57q.vce | 6 | 126.8 KB | May 26, 2020 |
LPI.Braindumps.102-500.v2019-09-10.by.Amir.29q.vce | 4 | 34.07 KB |
Similar LPI Video Courses
Only Registered Members Can Download VCE Files or View Training Courses
Please fill out your email address below in order to Download VCE files or view Training Courses. Registration is Free and Easy - you simply need to provide an email address.
Log into your ExamCollection Account
Please Log In to download VCE file or view Training Course
Only registered Examcollection.com members can download vce files or view training courses.
SPECIAL OFFER: GET 10% OFF
Pass your Exam with ExamCollection's PREMIUM files!
SPECIAL OFFER: GET 10% OFF
Use Discount Code:
MIN10OFF
A confirmation link was sent to your e-mail.
Please check your mailbox for a message from support@examcollection.com and follow the directions.
Download Free Demo of VCE Exam Simulator
Experience Avanset VCE Exam Simulator for yourself.
Simply submit your e-mail address below to get started with our interactive software demo of your free trial.
Add Comments
Feel Free to Post Your Comments About EamCollection's LPI 102-500 Certification Video Training Course which Include LPI 102-500 Exam Dumps, Practice Test Questions & Answers.