The original Japanese version is available here.
Yesterday I went out to the Nagoya office on my first business trip in a while. One of the IT supporters in Tokyo who joined us last year said pathetically that he had never been to the Osaka or Nagoya offices, so after a discussion among our respective supervisors, we decided to take him to Nagoya and Osaka for two days. On the bullet train to Nagoya, I took a Starbucks coffee to wake myself up, but my eyelids remained heavy and I headed to the rendezvous point. We went from Nagoya to Osaka that day, had dinner together, and went to Osaka office to work together the next day. I felt something strange, and probably he also felt something strange as I’m Japanese but he is not Japanese. The way of thinking on our duties is not the same.However, our goal is to provide a better IT environment, so we should be able to build a cooperative relationship.
Ports
Now, let’s do the same thing with Ports. First, create a ports tree. To make the ports tree, use the portsnap command.
First, fetch ports tree to the /var/db/portsnap directory.
Extract the fetched material to /usr/ports.
Incidentally, once the ports have been extracted to /usr/ports, after the next fetch, an update need to be used with portsnap command. We can apply only the difference between /var/db/portsnap and /usr/ports, to /usr/ports directory.
Now let’s find out the older ports with the pkg command.
There were many. Now let’s compile and update these ports with the default compile options. At this time, we declare that we will accept the default options as they are.
The portupgrade command compiles the new ports and replaces the older versions with newer versions.
The source code is downloaded and stored in the /usr/ports/distfiles directory.
Onlt one port seems to be failed to update. We will try the same thing again.
We see another error. We try to address. The error states that open-vm-tools conflicts with open-vm-tools-nox11. The currently installed version is nox11. The new one I am trying to install is apparently the X11 version. In addition to this, there is another message. It also says that the name open-vm-tools-nox11 has changed to open-vm-tools.
This could be OK, but I normally don’t use the GUI basically, we will compile it as a nox11 version. First, look at the Makefile in the /usr/ports/emulators/open-vm-tools directory. It says to remove the LIBNOTIFY and X11 options when FLAVOR is nox11. This seems to be the ones we need to modify.
Now let’s put that option in /etc/make.conf.
The nox11 name is no longer in the ports name, but I removed the options related to X11 , so it should be the nox11 version of vmware tools when it is compiled.
Let’s check it.
The libX11 library is not used, so this looks good. In fact, during the compilation process, the filesystem became full and stopped in the middle of the compilation process. This is partly due to the fact that I included the tools necessary for the compilation process, partly due to the fact that I downloaded the source code, and partly due to the fact that I included the documentation. open-vm-tools documentation compiles the TeX source to create a readable file. The TeX software for this seems to be very large. The obvious way to deal with this is to either make the file system larger or to not include the documentation. Reading documentation is important because it is the basic tasks of system administration, but considering that we are in the Internet age, documentation can be read anywhere in the internet. So, we will talk about how to make the file system larger another time, but we will re-install the software we want to include with the option to not include the documentation. From the articles in the past, the thing I installed was pdksh py38-speedtest-cli samba413 portmaster portupgrade unix2dos sudo bash open-vm-tools-nox11 only. I will add the option to not include the documentation and re-install from ports. This is not something related to this compile task. But when I started using 4.2BSD long ago I first tackled the task of how to print TeX sources on a printer. I asked a university professor who likes our computer system and get the TeX source code on MT, extract it to a file, and compile it over several days to produce TeX system. I remember compiling the manual in TeX, converting it to a dvi format file, converting it to PostScript using dvips, and printing it out on a PostScript printer to make a paper manual. Of course, dvips was compiled from source code as well. Sorry if I remember it incorrectly as it is several decades old. m(_ _)m I’ll get back to the original. For example, to recompile bash, you can do it like this.
This is an example of bash, but be careful when reinstalling pdksh. Do it from the console as root user, as you will break your own footing. Before you do this, remove everything you’ve compiled and re-install them from ports, since every package has its own documentation and it’s tedious to go through it for each application. Before you forget, put the no document option in /etc/make.conf file.
Oh, by the way, the /etc/make.conf file seems to have appeared suddenly here. What this is, is a file that allows you to specify compile options when we execute make command. You can change the options by explicitly typing “make config”.
It looks like this.
Options marked with [x] are defined options. The DOCS option appears to be defined by default. Revert the /etc/make.conf and try again. Pressing Ctrl-C to exit and revert the /etc/make.conf.
This is not something related to our task. If you are not satisfied with a more beautiful screen, try setting the TERM variable to “xterm” to get a more pleasing appearance.
Because it is stated that xterm is based on vt220, so I think it will work properly with basic vt100. Therefore, if you set TERM to” xterm” in the configuration file and terminal id to” vt220″ in Tera Term, it should work perfectly.
Return to the original task. Then run make config.
The option you want to remove is now removed. In case you pressed OK here to save the options, the saved contents will be saved like this. Individual options files have higher priority than /etc/make.conf.
Currently, /etc/make.conf can be used for all ports, so this file should be deleted. Now that you are ready, delete all installed packages. Since pdksh running as your footing will also disappear, edit /tmp/cmd file to avoid deleting pdksh, and then run /tmp/CMD. Of course, you can type each pkg command by hand. If it is not too much trouble 🙂
We were able to remove it as planned.
Now, we will replace all packages with ports with lots of compilation. Write a simple script and run it. It will probably take some time. Stay tuned!
It will take time… Good night ZzZ
Well, the situation is as follows: the compilation seems to be complete.
Finally, pdksh is rebuild from the source code on the console as root user.
Finally, make sure that the bug fixes during the package installation are still there. When I tried to check, I found that the number of startup scripts was different, and the application that we fixed the bugs was also gone. I assume that they are probably no longer needed due to dependencies.
In the meantime, let’s reboot the server to see if it works as expected.
After rebooting, it says nmbd is now the master browser. samba413 seems to be OK. I was able to log in, so ksh seems to be ok too.
The port related to open-vm-tools also seems to be OK.
dbus daemon is also OK.
Finally, let’s also activate the avahi related ports.
The bash is also installed. The disk usage has been cut in half. I am happy and satisfied 🙂
I have written about FreeBSD maintenance in two parts, but I think ports is much more flexible in its operation than packages. So, in what cases would you use ports? For example, you can use php version 7.4, 8.0, or 8.1 in ports tree. If you need apache 2.4 and php is also installed as its dependencies, then the port default version 8.0 will be installed. This can be a problem if you want to keep php 7.4 for other applications. In such a case, you can use ports to explicitly state what php version is required in the /etc/make.conf file, then any application can be configured with that php version.
Alternatively, package based maintenance is recommended if all the required applications created with the default configuration options work as expected. If not, and you need special configuration options, or if the software does not work as expected with the standard options, or if you need to create /etc/make.conf or change the source code before compiling when the software itself seems to have bugs, then ports based maintenance is recommended. Incidentally, I remember a long time ago package samba had problems joining the M$ domain, and I had to compile it with different options. There are many other situations where you will use ports, for example adding ldap for radius authentication.
Finally, I would like to compare the results of maintenance at the same time in ports and in the packages. First, after installation with ports, I removed unnecessary applications with pkg autoremove.
If you run pkg version on both servers and compare the files, you will get something like this
There seem to be some subtle differences, such as usage of some X11-related libraries or not, and some application names have changed. It is possible that the ports application was re-compiled without the DOCS option, which may have affected the results. However, despite the name change, I was able to update the installed applications to the same version and the latest version, so I think I can achieve my goal either way.
On my way back from Nagoya to Osaka, I was able to take a walk in Osaka City for the first time in a while. This scenery was very familiar to me, but I was thrilled to see the scenery that seemed to have changed, but hadn’t. I took a lot of pictures with my cell phone camera as I strolled around. I don’t remember the scenery being this beautiful.
Advertisement below
コメント