Serializer for Remote Agency 2

In the next major release of Remote Agency, the default serializer will be changed to JSON, from Json.net, instead of DataContractSerializer shipped with dotnet runtime.

This change is taken because the type support, especially the generic type support, is too weak in DataContractSerializer, and many user defined class is not marked with [DataMember] correctly. This change will also make it possible to serialize and deserialize data in one phase, instead of 2 phases in version 1, because the serializer will recognize the generic type automatically, without code specified generic types to be extracted in advanced.

New version plan of Remote Agency

I am excited to announce that Remote Agency will have one major update, version 2 in late this year.

Key features will be included in new version:

  • Speed up by combining serializing.
  • DataContractSerializer will be merged into main library. You can still use your own extended serializer, but this one will be shipped within the main library. Therefore, DataContractSerializer.EasyEncapsulation will be removed from the new version.
  • Reference to Roslyn directly, without CSharpRoslynAgency package.

Compatible issues:

  • If you have your own serializer, you need to rebuild one following new standard.
  • Facade classes will have some minor changes. You need to change your code working with them. In general, the amount of changes in each project will not exceed 10 lines of code.
  • There will be a new event for routing of the messages. The old one still works, but with forcible serialization, like in version 1.

There are many changes to be taken care within Remote Agency. I hope all my rest time in this year can make this change born.

Cheers,
Allen

Warning: When Upgrading to Ubuntu Server 20.04

Ubuntu, including server, 20.04 is launched several days ago. Many servers with 19.10 or earlier system are planed to upgrade soon. There are some issues should be noticed before you process.

1. If do-release-upgrade returns nothing found, you may want to use

do-release-upgrade -d

instead.

2. Some servers will be stuck with “Updating database of manual pages” process. In my tests on about 20 servers, about 20% servers will pass it with no more than 2 minutes delay. More than half servers, mainly on Azure, stuck there for 20-40 minutes. During this time, around 100 GB data are read from disk with 100% CPU using, reported by Azure portal. I don’t know what it read. All my files on the server cost no more than 20GB disk space. One of my server, hosted on Azure, costs more than half day so far (and not finished yet), more than 200GB data read. One server failed in that step, SSH drop and cannot reconnect at all. Before this problem solved, I strongly NOT recommend to upgrade your product server.

Update: The one stuck on Azure resume to idle after 14 hrs, 626.14GB reading and 27GB writing. Due to dead SSH process, I have to try to reboot the server. But the server never come back online. A kernel panic captured by Azure console while booting:

Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-1010-azure #10-Ubuntu
Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007  06/02/2017
Call Trace:
  dump_stack+0x57/0x7a
  ? rest_init+0x50/0xb0
  panic+0xfb/0x2d7
  ? do_execve+0x25/0x30
  ? rest_init+0xb0/0xb0
  kernel_init+0xfb/0x100
  ret_from_fork+0x35/0x40
 Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

3. Upgrading will replace php 7.3 with 7.4. If some site is powered by php-fpm with Nginx, you may need to change your web site configuration file in Nginx available sites folder. All packages installed by pip3 will be dropped, not uninstalled properly. You may want to uninstall them if you don’t want to use it any more before upgrading system. Or, you can reinstall them after upgrading.

Site moved back to Linux, again.

That’s the second time, lol. People fails in the same way huh?

I have used Azure Web Apps (on IIS) to host this website for more than 1 year and it turns out it is not good enough to run WordPress.

In the last year, the site was running in a very low speed. You may not observe it due to cache plugin, but I have to face it when publishing anything. The response time is around 20-60 secs for every process, proven by the chart displayed on the portal of Azure.

I also tried to use the Linux version of WordPress published officially using Azure Web Apps (on Nginx I guess). It’s faster, but still not fast enough, and the most critical is that’s not stable. Due to something unknown, it keep rolling config file back to the last version.

Finally, I decided to move all sites back to Nginx on Linux server without any SaaS solution. If you are facing this problem or want to host WordPress on Azure, you should consider to use a Linux server yourself instead of those official packages.

On more thing, there is another site powered by ShortUrl on the same web app, which need more time to move due to ShortUrl is built on DotNet Framework and is not able to run on Linux. My friend and I are rebuilt this program on DotNet Core 3 and it will be published on Github later.

Deploy a dotnet core site on nginx and systemd

This article is about how to deploy an ASP.Net core 3.1 site on nginx and systemd.

Preparation:

  • Prepare a server with nginx and systemd.
  • Install dotnet core support on server. Please check Microsoft site for details.
  • Build the binary files of the site to be deployed.

Step 1: Upload files

Make a folder in the server to be used to store site files. This folder will be marked as <SITEPATH> in all files below.

Upload your site files into this folder.

Give the permission to this folder.

sudo chown -R www-data:www-data <SITEPATH>
sudo chmod -R 755 <SITEPATH>

Step 2: Create systemd service

Create a service file. I suggest to put this file in the same folder of the site, aka <SITEPATH>. Let’s name it as myapp. You could change the name.
nano <SITEPATH>/myapp.service and enter this text below:

[Unit]
Description=<A_DESCRIPTION_TEXT_HERE>

[Service]
Environment=ASPNETCORE_URLS=http://localhost:<PORT_NUMBER>
Environment=ASPNETCORE_ENVIRONMENT=Production
WorkingDirectory=<SITEPATH>
ExecStart=/usr/bin/dotnet <SITEPATH>/<ENTRY_FILE>.dll
SyslogIdentifier=<A_NAME_HERE>
Restart=always
RestartSec=10
KillSignal=SIGINT
User=www-data

[Install]
WantedBy=multi-user.target

You should specify the description, port number, site path, entry file (main file), and the name to be used in syslog. Port number need to be different than all used by other services.

Link the file to systemd folder by ln -s <SITEPATH>/myapp.service /etc/systemd/system, reload systemd by systemctl daemon-reload, then start the service by systemctl start myapp.service. If everything goes will, you can see the port is listed in lsof -i -P -n | grep LISTEN. At last, set this service to start with system by systemctl enable myapp.service.

Step 3: Create nginx site.

Create the site file in sites-available folder by nano /etc/nginx/sites-available/<YOUR_SITE_NAME>, and enter this text below:

server {
    listen 80;
    listen [::]:80;
    server_name <SERVER_DOMAIN>;
    
    location / {
        proxy_pass http://localhost:<PORT_NUMBER>;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection keep-alive;
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

You should specify the server domain name and the port number which is chosen for this app.

Link the file to enabled sites by ln -s /etc/nginx/sites-available/<YOUR_SITE_NAME> /etc/nginx/sites-enabled. Test config by nginx -t. If there is nothing wrong, apply the setting by systemctl reload nginx.

Further: Certbot

If you want to use certbot to apply a free ssl certificate to this site, the nginx plugin shipped with certbot can handle that without any problem. Use certbot with the nginx parameter to finish this job: certbot --nginx.