Preparation

1. Download Visual Studio Code from code.visualstudio.com and install it. 2. Install plugin “Remote - SSH” in the Extensions view

3. Open settings. Check the box for “Remote.SSH: Lockfiles In Tmp” and “Remote.SSH: Show Login Terminal” File locking does not work when the home directory is mounted from an AFS. Setting the path of lockfiles to /tmp solves the problem. For more detail, see https://github.com/microsoft/vscode-remote-release/issues/540 For the second setting, VS Code should automatically prompt you to enter the password, but I had some trouble seeing the prompt before. I suggest enabling this so the password is entered in the terminal like normal ssh.

SSH Configuration

1. In the Remote Explorer view, click the Configure icon at the right of “SSH TARGETS” 2. Select the first SSH configuration file to edit 3. Add the CS Lab host to the file using the SSH config file format

For example,

Host CSLab
    HostName best-linux.cs.wisc.edu
    User szhong

If you want to connect to a machine that is only accessible inside the department network, you can use ProxyCommand. Take mininet as an example:

Host Mininet
    HostName mininet-xx.cs.wisc.edu
    User mininet
    ProxyCommand ssh -W %h:%p CSLab

Optionally, If you are on macOS and Linux and you want to reduce how often you have to enter a password, you can add the following entry to the config file

Host *
    ControlMaster auto
    ControlPersist  600
    ControlPath  ~/.ssh/%r@%h-%p
    Compression  yes

It reuses the ssh connection when you connect to the machine next time (within the timeout), so you don’t need to enter the password or do anything.

Remote SSH

You can now remote SSH to the CS Lab by clicking the newly-added entry under “SSH TARGETS” A new VSCode windows will pop up with the bottom right corner showing “SSH: CSLab”

Open a directory and happy coding :D

Recommended Plugins

• Live share is pretty helpful for pair-programming & group projects. I have a tutorial about this at https://shawnzhong.com/2019/02/28/pair-programming-using-vscode-live-share/

• For xv6 projects, you can install the “Native Debug” plugin for debugging. Along with the live share plugin, you can have collaborative debugging! See previous tutorial at https://shawnzhong.com/2019/03/25/co-debug-xv6-on-windows-using-vscode/

• If you are developing C or C++, the official C/C++ plugin is very useful for auto-completion, linting, etc.
• For Java developer, I suggest using Language Support for Java(TM) by Red Hat. Note that all the plugins are running at the remote machine and this plugin is hungry at the memory. If the target machine has less than 1G of memory (say mininet VM), Java Language Support by George Fraser is preferred as it has less memory footprint.
• The Resource Monitor plugin displays CPU frequency, usage, memory consumption, and battery percentage remaining in the status bar. Pretty helpful for remote machines with low resources.

Preparation

For security reasons, the remote desktop service (port 3389) is not accessible from the public internet. You can either connect to the CS Department VPN or use ssh port forwarding. To connect to the VPN, you first need to download and install AnyConnect (not GlobalProtect) from here. Enter dept-ra-cssc.vpn.wisc.edu for the server address, and choose the group to be COMP_SCI_SPLIT.

Alternatively, you can use ssh port forwarding to get access to the remote desktop service. Run the following line in your command line and enter your password.

ssh -fNT -L 3389:localhost:3389 <cs-login>@<server>

Here, -f stands for background, -N means no remote command, -T disables pseudo-terminal allocation and -L 3389:localhost:3389 forwards the 3389 port at the remote server to the local computer. You can choose <server> from the following list. Avoid using best-linux.cs.wisc.edu, since we don’t want to connect to a different server each time.

• rockhopper-01.cs.wisc.edu through rockhopper-09.cs.wisc.edu
• royal-01.cs.wisc.edu through royal-30.cs.wisc.edu
• snares-01.cs.wisc.edu through anares-10.cs.wisc.edu
• emperor-01.cs.wisc.edu through emperor-07.cs.wisc.edu

Connect to Remote Desktop

For Windows users, press Ctrl + R to open Run and run the program mstsc. (Or navigate to Start Menu -> All Programs -> Accessories -> Remote Desktop Connection). This program should be preinstalled on all Windows machines. Set the remote computer to be one of the CS Lab computers above (or localhost if you are using SSH port forwarding), and enter your user name.

For Mac users, download Microsoft Remote Desktop from here, and follow the configuration for Windows.

Since Microsoft Remote Desktop is also supported on Android and iOS, you can connect from your mobile devices! Here is an example at iPad with touch screen support:

How is it useful?

There are a lot of programs pre-installed on CS Lab computers, so you don’t need to configure the environment on your local computer. Examples include:

• Scientific computing: Matlab, Octave, Maple
• Data analysis: R, Jupyter Notebook, Python (with pandas, numpy, matplotlib)
• IDE & editor: VSCode, Eclipse, Atom, Sublime, Vim, EMACS
• Other: VirtualBox, TeXstudio, Slack, LibreOffice

You can start a VSCode Live Share from a CS Lab computer, and edit the code from your local computer, or share the link with your teammate for collaboration. I wrote a tutorial about setting up Live Share and xv6 collaborative debug. Feel free to check them out.

For debuging xv6 using VSCode, you need to install the Native Debug plugin, and your launch.json should look something like this:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "gdb",
            "request": "attach",
            "name": "debug",
            "executable": "./kernel/kernel",
            "target": ":25784",               // replace this with your debug port
            "remote": true,
            "cwd": "${workspaceRoot}",
            "valuesFormatting": "parseText"
        }
    ]
}

You can also install CLion on CS Lab computers, and work on the projects via remote desktop.

Note that your home folder (e.g., /u/s/z/szhong) is mounded from a network location, so it will be relatively slow to run programs from there. One workaround is to install programs under /nobackup, which is stored on the local disc of the computer you connected to. To install CLion, you can download JetBrains ToolBox from here, and set the installation folder to /nobackup/JetBrains

One More Thing

If you set the server address to be rd.cs.wisc.edu, you can connect to a Windows Remote Desktop.

References

https://csl.cs.wisc.edu/services/remote-access/department-vpn https://csl.cs.wisc.edu/services/remote-access/windows-remote-desktop-howto

Preparation

For Windows users, install gcc with MinGW, or install Clang For Mac users, install Clang using `xcode-select –install` For Linux users, make sure you have gcc installed. Open CLion and make sure that the run button is clickable with toolchains configured correctly.

Run Program with Sanitizer

To run a program with sanitizer, we need a special flag -fsanitize to the compiler. Common options include: -fsanitize=address, -fsanitize=thread, -fsanitize=memory, -fsanitize=undefined, -fsanitize=leak. A full list of options can be found here. Note that it is not possible to combine more than one of the -fsanitize=address, -fsanitize=thread, and -fsanitize=memory checkers in the same program, so you may need to toggle the options multiple times for a comprehensive checking. For testing, let’s add the following line to the CMakeLists.txt file:

set(CMAKE_C_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address,undefined -g")

When you run the code, you should be able to see a sanitizer tab next to the console.

Thread Sanitizer Example

Here is a poorly-written multithreading program:

int counter = 0;
pthread_mutex_t lock;

void *inc() {
  pthread_mutex_lock(&lock); // lock not initiazlied
  counter++; // thread contention
  pthread_mutex_unlock(&lock);
  return NULL;
}

void thread_bugs() {
  pthread_t tid;
  for (int i = 0; i < 2; ++i)
    pthread_create(&tid, NULL, inc, NULL);
  printf("%d", counter); // print the result before join
  pthread_join(tid, NULL); // the first thread is not joined
}

Add the following line to the CMakeLists.txt to enable the Thread Sanitizer

set(CMAKE_C_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=thread -g")

When the program is executing, the sanitizer will generate a report for thread-related bugs. Be aware that your program might run significantly slower with sanitizers enabled. The sanitizer noticed that two threads are reading/writing to the same memory location at the line counter++;, since we the locked is used before initialized.

There is also a data race between counter++ and the print statement since the main thread did not wait for one of the child threads.

Finally, there is a thread leak by the same reason above.

Address Sanitizer Example

To enable the Address Sanitizer, you need to add the following line to the CMakeLists.txt

set(CMAKE_C_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address -g")

It helps you detect heap overflow, which may happen when you incorrectly calculated the size.

Here is an example of overflowing a stack-allocated array

The Address Sanitizer also checks for using freed pointers. Note that it shows you where is memory is allocated and freed.

Here is a silly example of freeing the same memory twice, but it will be less noticeable when different pointers are pointing to the same heap location.

References

https://clang.llvm.org/docs/UsersManual.html https://www.jetbrains.com/help/clion/google-sanitizers.html

Preparation

For Mac users, run the following command to install Command Line Tools, which includes llvm (similar to gcc) and lldb (similar to gdb).

xcode-select --install

For Linux users, make sure you have gcc and perf installed. They should be pre-installed for Ubuntu. If not, you should be able to figure it out :) Open CLion and make sure that the run button is clickable with toolchains configured correctly.

Run CPU Profiler

Run the profiler by clicking the run button next to your main function and choose Profile(, or click the button next to stop at the toolbar)

The program will run in profile mode, and a report will be generated by the tool. You can open the report by clicking the Profiler panel on the bottom left corner. In the Flame Chart tab, you can see a visual representation of the execution time. You can start from the bottom and move up, following the code flow from parent to child functions.

In the Call Tree tab, you can see a tree of function calls with the corresponding execution time.

In the Methods List tab, a list of methods is presented ordered by decreasing execution time.

Reference

https://www.jetbrains.com/help/clion/cpu-profiler.html http://www.brendangregg.com/perf.html https://perf.wiki.kernel.org/index.php/Main_Page

Configure Build Task

To simplify the workflow, we can set up a task in VSCode for building xv6. First, open the folder for xv6 in VSCode and open “Terminal > Configure Tasks…” in the menu.

On the popup window, choose “Create tasks.json file from template” and copy the following content to tasks.json. (Equivalently, you can directly create tasks.json under ./vscode folder and past the lines below)

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "compile xv6 and run in debug mode",
            "command": "bash",
            "args": [
                "-c",
                "make && make qemu-nox-gdb"
            ],
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": true,
                "panel": "new",
                "showReuseMessage": true,
                "clear": true
            },
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

This file creates a default build task that compiles xv6 and runs it in debug mode.

To test whether the task is configured correctly, press Ctrl+Shift+B (or open “Terminal > Run Build Task…” in the menu). You should be able to see that the command make && make qemu-nox-gdb is executed in the bash of Linux subsystem.

Add Debug Configuration

To enable remote debugging, you need to install a plugin called Native Debug. You can install it in the Extensions tab on the left (or press Ctrl+P and run ext install webfreak.debug)

After Native Debug is installed, open “Debug > Open Configurations” in the menu. and past the following lines to launch.json. (Or equivalently, create launch.json under ./vscode folder and past the lines below)

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "gdb",
            "request": "attach",
            "name": "debug xv6",
            "executable": "kernel/kernel",
            "target": ":26000",
            "remote": true,
            "cwd": "${workspaceRoot}",
        }
    ]
}

To test whether debugging is configured correctly, add a breakpoint at kernel/proc.c:266 by clicking the space left to the line number and press F5 for debugging (or open “Debug > Start Debugging” in the menu). You should be able to see the program stops at the specified line with variables and call stack shown at the left.

Congratulations! You just set up the debugger for xv6! Be familiar with the first 4 icons in the floating toolbar. They are Continue/Resume, Step Over, Step Into, and Step Out respectively.

You can also watch a variable in the WATCH panel, such as ptable->proc[0]->name. To set a conditional breakpoint, open “Debug > New Breakpoint > Conditional Breakpoint” in the menu.

Collaborative Debugging

If you haven’t heard about VSCode Live Share or haven’t installed it, you can check my previous tutorial: Pair Programming using VSCode. Click the live share button on the bottom of VSCode, and share the invitation like to your partner. Your partner can join the debug session and control the debugging process by clicking the button on the toolbar. Note that the screenshot below is on macOS. The variables, call stack, and breakpoints are all synced to this computer.

References

https://docs.microsoft.com/en-us/visualstudio/liveshare/use/vscode https://code.visualstudio.com/docs/editor/debugging https://code.visualstudio.com/docs/editor/tasks

Preparation

1. Download Visual Studio Code from code.visualstudio.com and install it. (You can also use Visual Studio if you already installed it, but this tutorial will be focused on VSCode.) 2. Open a folder that you want to work on. I will use xv6 as an example.

3. Open the extension tab on the left, search for VS Live Share Extension Pack, and click install. Restart the editor if prompted.

Start a Live Share Session

1. Click on Live Share at the bottom left. An invitation link will be copied to the clipboard.

2. Send the link to your partner. He/she will be able to open the link in VS Code and join the session (possibly required to login via Microsoft account or GitHub).

3. Once your partner joins the live share, you should be able to see his/her cursor in the editor.

Some Useful Tricks and Tips

By default, your partner will follow your cursor when you are moving. You can disable it in the Live Share tab (see screenshot below).

During VSCode Live Share, you can open an integrated terminal by pressing Control + `, and the terminal will be shared across the session. It’s read-only by default, but you can change the permission in the Live Share tab as well.

I didn’t use this feature so often, but you can actually start an audio call in VSCode.

Reference

https://code.visualstudio.com/blogs/2017/11/15/live-share https://moduscreate.com/blog/remote-pair-programming-made-easy-with-vscode-live-share/ https://visualstudio.microsoft.com/services/live-share/

Enable WSL (Windows Subsystem for Linux)

1. Search for “Turn Windows features on or off” in the start menu and open it. 2. Select “Windows Subsystem for Linux” 3. Restart your computer when prompted

Install Linux Distribution

1. Open this link https://aka.ms/wslstore on Windows. You will be redirected to an installation page in Microsoft Store. (If this link doesn’t work, you can manually open Microsoft Store and search for Ubuntu.) 2. Download Ubuntu. This usually takes about 5-10 minutes depending on your Internet speed.

3. Once Ubuntu is downloaded, you should be able to see it in the Start Menu. Launch the program. It will take some time to set up the system for the first time. 4. After that, you will be prompted to create a new user for the subsystem. This does not need to match your Windows username or CS account. Once the account is created, you should be able to run the familiar Linux commands inside the subsystem.

Note that the working directory is /home/<username>. If you want to access the disk on your Windows machine, you can cd to /mnt/<drive letter>/<path>.

Install Toolchains and QEMU

Run the following command in bash. (Note: You can right-click the terminal window to paste the command.)

sudo apt-get update
sudo apt-get install git nasm build-essential qemu gdb

You will be prompted to enter yes to confirm installation. The installation process takes about 30 minutes.

After apt-get is done, you should be able to run commands like gcc, gdb, qemu, etc.

Compile xv6

Change the working directory to your Windows machine and copy xv6 from CS Lab

cd /mnt/c/Users/ShawnZhong/Downloads
scp -r szhong@best-linux.cs.wisc.edu:/p/course/cs537-shivaram/xv6-sp19 .

You can then use the following command to build and run xv6 locally on Windows.

make && make qemu-nox QEMU=/usr/bin/qemu-system-i386

Congratulations! You have xv6 running locally on your Windows machine. Since everything is on your local computer, you don’t need to sync the files to the server anymore! It also makes the debug experience much better since the debugging port is open on your local computer (i.e., no more port forwarding).

Reference

https://gcallah.github.io/OperatingSystems/xv6Install.html https://docs.microsoft.com/en-us/windows/wsl/install-win10

1. Preparation

Note: You can skip this part if you are compiling xv6 on your local computer or you are already in the CS Lab. 1. SSH to a CS Lab machine. Please use a specific server in the following list instead of best-linux.cs.wisc.edu. (best-linux.cs.wisc.edu is the Linux machine in the CS labs that currently has the fewest number of other users logged in to it. We don’t want to use this because it might change over time.)

• rockhopper-01.cs.wisc.edu through rockhopper-09.cs.wisc.edu
• royal-01.cs.wisc.edu through royal-30.cs.wisc.edu
• snares-01.cs.wisc.edu through anares-10.cs.wisc.edu
• emperor-01.cs.wisc.edu through emperor-07.cs.wisc.edu

2. Copy xv6 to your working directory on a CS Lab machine, build the source, and run xv6 in debug mode.

cp -r /p/course/cs537-shivaram/xv6-sp19 .
make
make qemu-nox-gdb

3. Record the port number for gdb server. I always have 25784, but it might be different for you. (What qemu-nox-gdb does is that it runs a gdb server at localhost:25784 so that gdb can later connect to this server to debug the code.)

4. Open CLion and sync the folder to your local machine. Please refer to this tutorial if you don’t know how to do this.

5. Open another terminal window, and use the following command to forward the port (recorded in step 2) on the remote server to your local machine. (This is called SSH tunneling or SSH port forwarding so that we can access the gdb server running on the CS Lab machine via localhost:<port> on your local machine) Note: Please leave the terminal window open at the background in the following steps.

ssh -L <port>:localhost:<port> <username>@<server>.cs.wisc.edu

2. Configure CLion

1. Click “Edit configuration” on the top-right 2. Add new configuration of type “GDB Remote Debug” 3. Set ’target remote’ args to be localhost:<port> 4. Choose the symbol file to be <local_folder>/kernel/kernel. (If you cannot find this file, build xv6 again and download the built folder to your local machine) 5. Set the system root to be <local_folder> 6. Add path mappings between <local_folder> and <remote_folder>

3. Run GDB Remote Debug

For testing, let’s create a breakpoint at kernel/proc.c:261 by clicking the space next to the line number (same as “b kernel/proc.c:261” in gdb). Click the debug button on the top-right corner. You should be able to see a debug tab open on the bottom left, which shows you the frames (same as “info frame” in gdb) and variables (same as “info variables” and “print <var_name>” in gdb). If the debugger doesn’t stop at the breakpoint, please go to section 5: Troubleshooting.

Here are some useful commands that you can use during debugging

• Step over: execute next line of code. Will not enter functions. (same as “n” in gdb)
• Step into: step to next line of code. Will step into a function. (same as “s” in gdb)
• Step out: run until current stack frame finishes (same as “finish” in gdb)
• Continue: continue running your program (same as “c” in gdb)
• Pause: pause the execution of a running program (same as Ctrl+C in gdb)

To create a conditional breakpoint, right click on a normal breakpoint to add the condition.

You can also directly type commands into gdb by switching to the gdb tab (when the program is paused)

4. Some Useful Tips

For better code analysis and navigation, you can mark your xv6 folder as Project Sources and Headers, and add the line “include_directories(<relative_path_to_include_folder>)” to CMakeLists.txt

Once the previous step is done, you can press F1 on a function/variable to see the documentation. There is also an option for showing quick documentation on mouse move at “Editor - General - Other”.

5. Troubleshooting

First, make sure that the debugger is connected to the remote server. In the debug tab, you should see something like “Debugger connected to localhost:25784”. If the message doesn’t show up, you need to check whether

• xv6 is running in debug mode (make qemu-nox-gdb)
• SSH tunnel is connected to the same server as xv6 and forwarding the right port number (ssh -L <port>:localhost:<port> <username>@<server>)

If the debugger is successfully connected to xv6, but it still doesn’t stop at the breakpoints, click the pause button at the left. If the debugger highlighted some code in the xv6 source folder, but the line number is wired, downloading the compiled xv6 from CS Lab server again should resolve this problem. This is because the symbol table on your local computer is not up to date after you modified the code and recompiled it on the remote server. If you got an xv6 (disassembly) window with commented assembly code, switch to the GDB tab and enter info sources. Make sure that the files can be found on your local computer. If you moved the xv6 source folder after compilation, try make clean and compile again.

If the debugger is still not working, feel free to contact me by email :)

6. Reference

http://man7.org/linux/man-pages/man1/gdbserver.1.html https://sourceware.org/gdb/onlinedocs/gdb/Server.html https://www.jetbrains.com/help/clion/debugging-code.html https://www.jetbrains.com/clion/features/run-and-debug.html

1. Configure Remote Toolchain

A toolchain is a set of development tools including compiler, linker, debugger, etc. We want to use set up the remote toolchain for our project so that we can compile and run codes remotely. 1. Open setting and navigate to Build, Execution, Deployment > Toolchains 2. Click add at the bottom 3. Select Remote Host instead of System at the right of Name 4. Click open in the Credentials line 5. Fill in the information for the remote host

Use a specific server for the host (e.g. royal-10.cs.wisc.edu) instead of best-linux.cs.wisc.edu, since we don’t want the project to be run on a different machine each time.

Here is a list of Linux server you can use:

• rockhopper-01.cs.wisc.edu through rockhopper-09.cs.wisc.edu
• royal-01.cs.wisc.edu through royal-30.cs.wisc.edu
• snares-01.cs.wisc.edu through anares-10.cs.wisc.edu
• emperor-01.cs.wisc.edu through emperor-07.cs.wisc.edu

6. If you have configured toolchain before, you need to drag the remote host to the top of the list to set it as the default toolchain.

Note 1: After you clicked OK, It may take some time for CLion to retrieve some information from the remote server. You can check the process by clicking the status information at the bottom of CLion. Please wait for that until you continue. Note 2: If cmake reports “CMake 3.13 or higher is required. You are running version 3.10.2”, you need to change the first line of CMakeLists.txt to “cmake_minimum_required(VERSION 3.10.2)”

Now you should be able to compile and run your code remotely on CS Lab machine by clicking the run button at the top right corner of CLion.

2. Remote Debug on CS Lab Machine

Now you can click on the line number to add a breakpoint and click the debug button to debug your code. If you are encountering segmentation fault, the debugger will stop at the line where segfault happens.

3. Some Useful Tips

1. Make good use of the following three buttons on the debug tab.

• Step over: go to the next line
• Step into: look into the function call
• Step out: get out of this function

2. You can add new watches to the variable list to check for a specific variable 3. Press F1 on a system function to show the documentation. You can also dock the documentation popup as a permanent tab on the right.

4. References

• https://www.jetbrains.com/help/clion/debugging-code.html
• https://www.jetbrains.com/help/clion/viewing-inline-documentation.html

Installation

You can download CLion from this link: https://www.jetbrains.com/clion/. It is commercial software, but you can get the student license for free here: https://www.jetbrains.com/student/. The installer will ask you to configure toolchains for CLion. If you have not installed any toolchains  (gcc/llvm/MinGW/Cygwin) before, you can just skip this part, since we are probably not going to compile or run the code on our local machine. You can follow the default configuration to finish the installation. BTW, If you are a big fan of vim, you can enable the IdeaVim plugin on the last screen.

Connect to the Remote Server

After you created your first project, go to “Tools - Deployment - Configuration”. Click the “+” button and select “SFTP” as the type. Under the connection tab, fill in the “Host”, “User name”, “Password” field, check the box for “Save password” (if you want to), and click “Autodetect” for “Root path”. Under the mappings tab, choose your deployment path on the server (I put all files under /private/CS537. You can choose whatever path you want, but don’t put it under /public) Now the remote server is configured. You can click “Tools - Start SSH session” to connect to the CS lab via ssh

Configure File Synchronization

If you select your project folder on the left and go to “Tools - Deployment”, you can see the following menu. You can enable the “Automatic Upload” option so that local changes will be uploaded to the server automatically. You can also click “Browse Remote Host” to check the files on the CS lab. For setting up the xv6 files, I suggest to copy them from /p/course/cs537-shivaram/xv6-sp19 to your private remote folder (e.g. /u/s/z/szhong/private/CS537/p1b), and then click “Download from CS Lab”. (Note that the deployment menu is also available if you right-click a certain folder or file so that you can manually upload/download a single file/folder)

Some Useful Tips

• Press Control (on Windows) or Command (on Mac) to jump between definition and declaration. (It’s pretty useful when navigating files in xv6)
• Press Control + Shift + F to search among all project files
• Double press shift to search for all file names/classes/actions…
• Press Alt + Shift + L (on Windows) or Command + Shift + L (on Mac) to reformat code, or you can use the plugin called “Save Actions” to perform reformat on save
• You can check the editing history under the menu “VSC - Local History - Show History”.

Download WordPress

1. Connect to CS Linux server

If you are using Mac or UNIX system, use the ssh command:

ssh cs-username@best-linux.wisc.edu

If you are using Windows, download PuTTY to connect to the server

Note: Replace cs-username with your username

2. Change directory to ~/public/html

Type cd ~/public/html in the terminal, and press enter

Everything in this directory will be public at http://pages.cs.wisc.edu/~cs-username/

3. Download WordPress file and unzip it

Use wget to download the file from wordpress.org

wget https://wordpress.org/latest.zip

And use unzip to unzip the files

unzip latest.zip

4. Wordpress installed!

Open http://pages.cs.wisc.edu/~cs-username/wordpress/, and you should see the page below

Create a Database on GearHost

1. Create an account on GearHost

https://my.gearhost.com/account/signup

2. Create a database

Open the “Database” tab on the left

Click “Create Database” button

Choose a database name, and select MySQL (free)

Click “Create Empty Database”

Record your database name, database server, username, and password

Configure WordPress

1. Open http://pages.cs.wisc.edu/~cs-username/wordpress/ 2. Fill in the database information, and click submit

3. Copy the content of wp-config.php

Since we don’t have the write permission to the server through webpage, we have to manually create this file

4. Go back to CS Linux server, and change directory to ~/public/html/wordpress

cd ~/public/html/wordpress

5. Open text editor, and create the file wp-config.php

nano wp-config.php

Note: You can also use vi or vim instead of nano, but nano is easier to use.

6. Paste the content

7. Control+X and press enter to save the file

8. Go back to the website and press install

9. WordPress installed!!!

Add Write Permission

1. Connect to CS Linux server and install “SSH SFTP Updater Support” plugin

ssh cs-username@best-linux.wisc.edu

cd ~/public/html/wordpress/wp-content/plugins/

wget https://downloads.wordpress.org/plugin/ssh-sftp-updater-support.0.7.3.zip

unzip ssh-sftp-updater-support.0.7.3.zip

2. Enable the plugin on Dashboard

Open http://pages.cs.wisc.edu/~cs-username/wordpress/wp-admin/plugins.php

Click “activate” below “SSH SFTP Updater Support”

3. Configure “SSH SFTP Updater Support” Plugin

Open http://pages.cs.wisc.edu/~cs-username/wordpress/wp-admin/theme-install.php?browse=featured

Choose any theme you want, and click the install button

You will see a pop window called “Connection Information”

This is because we don’t have permission to write file to the server through webpage

Choose SSH2 for connection type, since our CS server do not support FTP

Use best-linux.cs.wisc.edu for hostname, and your CS account for username and password.

Leave everything else blank, and click proceed.

Now you have the permission to write file to the server

Congratulations!

You have deployed WordPress on CS Linux Server!

# EOF