LUG

Why does a C program need to be compiled before it can be executed? Why does a C program need to go through the four steps of preprocessing, compiling, assembling, and linking to become an executable file? Let’s start with this simple C program.

Why Compile

This is not a simple question. We know that Python code does not need to be “compiled”, and you can run the result by entering a line of code, which is very user-friendly, isn’t it! This interactive runtime environment is called REPL (Read-Evaluate-Print-Loop), which reads the user’s input statement, executes the statement, outputs the value of the statement, and then returns to the waiting input state.

When we mention Ken Thompson, the first thing that comes to mind is the UNIX operating system he invented. For this, he won the Turing Award in 1984. In his Turing Award speech, Ken Thompson raised a profound question: Does seeing the source code of software mean there are no backdoors? Could there be self-replicating backdoors in compilers?

This paper published in “ACM Communications” is only three pages long and omits many details. The principle is a bit like a C program that outputs its own code, but it’s much more difficult. Following in the footsteps of the sages, I inserted a self-replicating backdoor into an open-source C compiler—tcc. This compiler, with the backdoor, will automatically insert a backdoor when compiling the source code of the Linux login program sulogin.

Yesterday, I was invited by USTC LUG to attend the 2014 Open Source Technology Conference (OSTC) hosted by CSDN. I would like to share with you the notes I took at the conference and my unreliable memory. If there are any errors or omissions, please point them out in the comments. Some of the pictures in this article are from CSDN’s official live broadcast. I obviously don’t have the speakers’ slides, but I heard that CSDN will release them in the next few days.

In the morning, I met the tall and handsome Thomas Yao and Wang Yong from Deepin (I didn’t take a picture).

Is the blunder far from us? Not really. A while ago, the LUG server malfunctioned and mistakenly sent out 70,000 text messages, depleting the balance of the school’s text message platform. It was not until the teacher from the network center called me that I found out.

The trouble started with the service monitoring script. It retrieves site information from the database, periodically visits the monitored sites, and if a problem is detected, it will send a text message alert to the website owner. When the service monitoring script fails to connect to the database, it will also send me an alert text message. Initially, it would not attempt to reconnect to the database, so it would only send an alert once, but the monitoring service could not automatically resume operation after the database was restored. This bug was discovered during a blog malfunction, so it was changed to automatically reconnect, but the logic for sending alert text messages was not modified, so if the database could not be connected continuously, it would keep sending.

To prevent text message bombing, the messages sent out had to go through my “risk control”, limiting the number of text messages sent to each phone number every 24 hours. Risk control is to query the text message log table in the database to get the number of text messages sent to this number in the last 24 hours. When the database crashes, the value queried is NULL, which is implicitly type converted to 0 in PHP, so it is considered that it has not exceeded the limit and is sent out. The school’s text message gateway also has no “risk control” , resulting in a large number of text messages flooding into the operator’s network.

Some users of the LUG VPN hope to use the VPN only for certain specific IPs, while OpenVPN defaults to using the VPN for all. Perhaps my search skills are too poor, I didn’t Google a reliable answer. Readers without patience can directly look at my solution:

1
2
3
4
5
6
7
8
9
10
11

$ echo "script-security 2" >>/etc/openvpn/client.conf
$ echo "up /usr/local/bin/remove-ovpn-defroute" >>/etc/openvpn/client.conf

$ cat /usr/local/bin/remove-ovpn-defroute
#!/bin/sh
(
    sleep 2 # wait for routing table to be flushed
    ip route del 0.0.0.0/1 dev tun0
    ip route del 128.0.0.0/1 dev tun0
) &
exit 0

Note: For those who are not familiar with mirrors, please read “How USTC Open Source Software Mirror is Made“ first.

Trouble Starts with iSCSI

The story begins on June 26, 2013. Mirrors has a disk array directly connected by a network cable, using the iSCSI protocol, with an XFS file system on it. Around 14:00 on June 26, stephen reported in the mailing list that mirrors was down. According to syslog, at 13:58 on June 26, the iSCSI connection timed out, causing sdg access failure, a large number of I/O operations were stuck, causing nginx to be stuck, mirrors HTTP could not connect. A few minutes later, I/O timed out, nginx returned to normal, but the sources on the disk array could not be used.

Today, Guangyu said that he wanted a summary of last year’s work, so this article came into being. The main work of LUG is divided into activities and network services.

Activities

Let’s review what happened in the past year (http://lug.ustc.edu.cn/wiki/lug/events)

Recruitment

Together with other clubs, we set up stalls in the second week of school, in the east and west activities. The stolen experience is: you can make some display boards and roll-ups to increase the exposure rate.

Although recruitment is quite hard, it’s fun to chat with students from various departments, and handing out flyers can also taste the often rejected taste. Gossip, the current president of LUG’s sister was found at that time~

Update (2014-09-29): Due to some inappropriate content in the mirrors configuration file, the configuration file is no longer public, and some links in this article have become dead links, I’m very sorry.

Due to the disk failure of the USTC open source software mirror (mirrors.ustc.edu.cn) disk failure, stephen, tux and I (boj) are not at school, and the mirrors have not fully recovered since the failure in July, it’s time to start over. This time the mirrors rebuild will be completed entirely by students on campus, which is also an opportunity to practice technology. Here, I will briefly explain what parts the open source software mirror includes and how to build it. Since sourceforge is still waiting for us to synchronize, we hope to restore basic services within three days and rebuild the entire system including synchronization within a week.

WTF?

The so-called open source software mirror is to synchronize some GNU/Linux distributions and well-known open source software repositories from the official site. Users can use the software repository mirror nearby by modifying the configuration file to speed up the download and reduce the load on the official site.

From 16:00 to 17:30 on August 21, the Poster session of the 2013 MSRA Summer Camp was held in the public exhibition area of Microsoft Research Asia. Participants included Microsoft Scholars attending the summer camp, members of Microsoft clubs from various universities, and MSRA Researchers & Interns.

Originally, I didn’t plan to present anything, but at the request of the event committee, I chose Blog and Freeshell as my presentation projects. Following the committee’s suggestion, I modified it to “Cloud Services in USTC”, a title that seems big and fashionable.

USTC mainly has four outbound routes: Education Network (CERNET), Telecom, Mobile, and Unicom.

These four exits each have their own characteristics, let’s go through them one by one:

Education Network

• The full name of the Education Network is “China Education and Research Computer Network” (CERNET), which connects universities and research institutions nationwide. The main node is in Beijing (the headquarters is in Tsinghua Science Park, next to Google), and USTC is the core node in Anhui Province.
• IPv4 bandwidth 2G
• IPv6 bandwidth 2G, relatively loose (Liuwei is IPv6, very fast)
• The north-south interconnection within the Education Network is quite congested during the day, and the network is more smooth at night. The north-south interconnection problem of other operators may be more serious.
• Access to other domestic operators and foreign countries is very slow
• The routing path on the network is not necessarily the shortest geographically, for example, the traffic from USTC to Beijing may have to go through Shanghai.
• Access to IPs outside the “free addresses” defined by CERNET is charged by traffic. Although it does not charge us directly, try to save money for the school :)
• Everyone is advised to use IPv6 when accessing resources within the Education Network