Becoming a customer (requires paying 20 eur using PayPal)

The developer of the publishing application registers one new user account for each new customer of the publishing application with the data centre service provider (Hetzner), after which the publishing application server can then be deployed.

The first prepayment is different from the subsequent ones in that the customer of the publishing application first sends 20 eur to the developer of the publishing application using PayPal and then this 20 eur is sent to Hetzner using the same payment service. PayPal payments are transferred without delay if there is money in the PayPal account or if the PayPal account is linked to a bank card.

There are several data centre service providers and one that seems to be very good is Hetzner, whose servers can also be located in Finland. In the case of Hetzner, the initial financial transaction would be as described in the image 1 meaning that customer makes a prepayment using PayPal to the PayPal account of the developer of the publishing application, from which the same amount is soon transferred to Hetzner as an prepayment. Later, the customer can also pay Hetzner's invoices directly by bank transfer.

Other data centre providers may not have the option of prepayment, so for them the initial and possibly later financial transactions too would happen as describe in the image 2 and which might also mean that deployment phase could arrive slightly sooner.

Basic features of a server that the publishing application uses and monthly payment

Resources such as disk space, memory/performance for server equipment are available on request. As minimum resources for a server, 4 GB of memory, and 3 vCPUs (processor time slots) have been considered as suitable. The server is a virtual server, i.e. the processor is used by multiple Hetzner clients. Dedicated servers, i.e. servers used by only a single customer, are more expensive. With what are defined as good basic resources, the monthly fee for a virtual server would be somewhere between 5 and 15 euros. Decentralising the publishing application to multiple servers works, but synchronising data between servers can cause problems that have not been encountered in testing, so for the time being the publishing server is only placed on one server, with the possibility of changing resources.

There is a lot of variation in the pricing of outbound data (images, etc.) between different data centre services providers, but customer should be able assume that both the amount of free outbound data traffic and the amount of disk space can be characterised as relatively high. The CPX21 server at Hetzner in the image 3 allows up to 20 TB of outbound data traffic before being charged separately. In practice, this limit cannot even be exceeded because the publishing application is configured to limit data traffic to a level that does not allow excessive traffic to accumulate. This, as well as many other issues, can be agreed separately.

Required to be used: CDN service (10 eur / year, paid using PayPal)

The publishing application is much more resilient to load on the server, and the images used in the works load faster when they are not always loaded directly from the server used by the publishing application, but from a CDN that resides between the user and the server. The abbreviation CDN stands for Content Delivery Network, which means, for example, that the images used in the works arrive in the user's browser from the nearest possible PoP server of the CDN service.

Pricing and special mention: the CDN service (BunnyCDN) can be pre-configured for the customer by registering a single new user account, making the necessary adjustments and then changing the email address of the CDN user account so that the customer can log in and attach his payment details to the user account. The customer would already have a PayPal account at this stage, so it is recommended to use it (trial period of 14 days). BunnyCDN has a rule that once a year, the customer must pay a minimum deposit of 10 eur. A previously paid prepayment will never expire. For that 10 eur, you can get 1 TB of data transfer, which could be enough for a low-traffic publishing application for a whole year. If the prepayments run out, the images from the publishing application will not be distributed via the CDN service until another prepayment has been made. These prepayments are non-refundable once paid.

Notice: There is a separate writing explaining how to set up the CDN service using images (see the writing "Ohje CDN-palvelun käyttöönottoon").

Separately bought domain name

The publishing application can be accessed from the Internet as soon as it is installed. If agreeable the publishing application may be set up to use a specific subdomain for e.g. testing purposes. Otherwise the customer needs to buy a domain name. Such can be purchased from a number of different providers (e.g. Namecheap), which typically also have (some kind of) management interface. The domain name purchased is always transferable from one registrar to another, unless you have given up some of your rights, such as ownership, when you buy it. At this time it is intended that a publishing application customer would buy the domain name himself, as even a novice can do it and thus there wouldn't need to be the hassle of transfering ownership rights.

Pricing: if you don't need a special domain name extension, the usual minimum price might be a little less than ten euros per year. The first year can often be free or at a good discount. There are several hundred different domain name extensions.

Notice: For a separately purchased domain name, these name servers (see image 4): hydrogen.ns.hetzner.com, oxygen.ns.hetzner.com ja helium.ns.hetzner.de.

Notice: Not of major importance, but as a quick note, if IPV4 addresses are not available for the publishing application due to their low global availability, IPV6 addresses are used. Cisco, for example, can tell you more about them: https://www.ciscopress.com/articles/article.asp?p=2803866

Refunding of prepayments

At least in the case of Hetzner, prepayments can be refunded for the remaining amount (minus the balance of the last invoice). However, in the case of some other data centre service provider, if the customer still has money left in the PayPal account of the publishing application developer and the invoices have been paid, the customer can get the remaining money back.

According to the information received from Hetzner's customer service, the refund will be made using the payment method originally used to make the payments, i.e. PayPal payments via the publishing application developer to the PayPal account and bank transfers directly to the bank account of the publishing application customer. It is not clear at the time of writing whether there is a service fee for a bank transfe, but in the SEPA (Single Euro Payments Area) it should not be very much.

Establishing customer relationship

If a data centre provider does not allow prepayments, customer can still transfer prepayments for a calculated number of months to the PayPal account of the developer of the publishing application or, perhaps more easily, transfer a rough amount sufficient for one or more monthly payments.

If a data centre service provider such as Hetzner allows prepayments to be received, customer's money is transferred directly from the PayPal account of the developer of the publishing application, as in the initial phase. Hetzner has a special feature that the customer can choose to pay the invoices directly to it using a bank transfer. Hetzner automatically deducts the server costs from the Credit Balance once a month. When making a bank transfer, the Hetzner user account's ID is entered as a reference number so that the amount sent is routed to the correct user account.

If requested separately, the customer can receive a copy of an invoice, but this is a manual operation, so sending a copy of each invoice might not happen. As an alternative, some data centre service providers offer the possibility of inviting a person to a team of some sort, which allows customer to view and perhaps also pay the bills in a web interface.

More business-like operations still ahead

The publishing application is not yet sold as a business, but as a private person, so at this stage the customer does not pay extra for product development, maintenance, etc.

Not in use, yet: secure connection to everyone accessing subdomain used for testing purposes

At this stage, while avoiding the accumulation of costs for the developer of the publishing application, no SSL certificate for secure connections has been implemented, but at some later point of time a wildcard-type SSL certificate (see image #23585) could be implemented, so that one SSL certificate could be used to enable security on all subdomains of the domain used for testing purposes. This would not be charged from customers and just mentioned for the sake of mentioning. For a user having a user account to the publishing application, access to it can be partially protected with a VPN connection. For more information, see "Rationale and guidance for obtaining a network address specific SSL certificate".

To get a feel for how to increase credit balance, two different ways of transferring money to Hetzner was tried: directly from bank account (Nordea) and using the Wise service. Both were paid on Thursday and on Monday, immediately after the weekend, the credit balance had increased using both. The service charge for Wise matched exactly the amount that was left to transfer to Hetzner. The bank did not charge a service fee. The fact that both the sender and the recipient were located in the SEPA (Single Euro Payments Area) certainly helped to speed up the transaction flow. Hetzner is a German company, where its headquarters are located.

Bank transfer using Wise

Wise's interface is not so complicated that it would need a lot of explanation. You can get off to a good start by clicking the "Send money" button. Since it seemed relevant to be able to assess the consequences of having something wrong with the transfer details, the name of the recipient (Hetzner) was set to the name of the bank and the reference number was not only set to the required Hetzner customer ID, but it also contained text string "Customer ID:", but just as quickly the payment was made available as with a bank transfer.

The payment intermediary Wise charged a service fee of 0.41 eur for a transfer of 10 eur, which is probably an acceptable amount. The amount that ends up in Hetzner's account is clearly shown and you can see from your own online bank that ten euros have been deducted from the account. The money transfer in this case has also gone through Trustly, which has the advantage that the identity is verified by a bank ID and no other proof of identity is required.

Bank transfer using own bank (e.g. Nordea)

In addition to the Hetzner IBAN, it is important to include the Hetzner customer number in the reference data. A slight mistake made in the other try out allowed to deduce that the customer ID in the reference number could also contain a little extra like "Customer ID:" before the actual customer number and the amount of money would still end up where it was supposed to. However, it is probably recommended to use only the customer number as reference number. Nordea Bank did not charge a service fee (it was probably included in the personal service package).

An online bank transfer could not be much easier. Just as easy as transferring money domestically. A slightly different amount was sent for the sake of differentiation, i.e. 3 euros, which ended up in full in Hetzner's account.

Other services and about proving identity

PayPal's Xoom service may be as good as Wise. Other payment services that have emerged as potentially viable include Azimo, Instarem, Revolut, MoneyGram and transferGo. There are some country restrictions on the location of the sender for payment intermediaries such as Western Union, SendMoney24, GlobalWebPay and Ria. Skrill could be a good one, but at the time of writing, individuals cannot use it to send payments to businesses.

Some of these services don't let you do much until you've proved your identity in somewhat cumbersome way, possibly requiring to take a selfie, and prove your address by scanning an invoice that came in the mail, for example. In the case of the Wise service that was tried, you can use Trustly as a payment method, so you don't need to prove your identity beyond your bank ID. According to the Wise website, Trustly is available in Estonia, Finland, Spain, Poland, Sweden and Denmark.

The customer may well be interested in testing the number of users the publishing application can handle, and such load testing is acceptable as long as it does not go on for hours. Even a minute of automated loading of some writing of a work, e.g. with a load testing application available online, is sufficient to get a good feel for it. In a single-server system, it should be possible to load one article with basic resources, e.g. 8000 times per minute with a response time of 70 ms. Considering that e.g. most blog posts on the internet get only a few hundred reads per month, the basic resources should be "just fine" for many purposes. Images of public works will always be loaded via the CDN service, if a prepayment for the CDN service has been made.

One quick way for the customer to reduce the load on the publishing application is to increase the cache time per work, which is 5 seconds by default. This caching means that e.g. one writing of a work is not generated separately for each page load, but the last one is stored on the server in a file which is used for e.g. the next 5 seconds or as long as it is configured to be. It can be up to two hours. The generating of a writing and other parts of a work causes always a moderate load on the server's processor, and there is always the possibility that there will be a lot of page load requests at once. Reading the generated part of the work from a file causes, by comparison, a very low load on server resources.

Load balancing of server hardware and software would not be fully utilized if the Linux server that first receives the incoming signals is configured to be highly restrictive in the outbound bandwidth. That would be done with the Linux's tc command (from "traffic control"), and the reason for its use could be e.g supposed threat that bots would be deliberately programmed to consume a monthly traffic by downloading moderate amounts of different content such as images and pages of works many times over a long period of time. One would probably prefer not to pay several hundred euros extra instead of the expected e.g. ten euros. It might be least stressful to be prepared to pay three times more than expected by keeping the bandwidth only slightly limited and hopefully finding out again and again that nothing bad happened.

Normally, many data centre service providers would charge for outbound data from servers of the publishing application after data transfer volumes exceed e.g. 20 TB, as in the case of Hetzner. This amount, i.e. 20 000 GB, is a large amount for a low traffic instance of the publishing application. To be on the safe side, an additional limitation is applied to the servers of the publishing application on a per-customer basis to prevent the monthly data transfer volumes from exceeding that 20 TB by limiting the transfer rate of the virtual network card of the server to 60 mbps or 7.5 MB/s (see calculation: https://www.wolframalpha.com/input/?i=60Mbps+in+TB%2Fmonth). The portion of the cost that exceeds the specified data transfer limit is referred to as 'overage costs' and the data that goes out of the server is referred to as either 'egress data' or 'outbound data'. If the data centre services are provided by a provider other than Hetzner or if 20 TB is otherwise not the limit for the overage costs, this will be explicitly mentioned before the conclusion of the service agreement.

If the number of visitors suddenly increase, it could make it difficult to log in with a username or do any kind of editing, for example, because the load would make everything very slow. The images in the writing "Changing the network topology of the publishing application" give few ideas about how to change network topology to make it all more resistant to high external load. Other quality of service improvements include simply adding more vCPUs for virtual servers to use or switching to dedicated servers. For a bit more information on these, see the writing "Becoming a customer of the publishing application".

Setting up a CDN service is relatively easy. The fifth step can be completed once the publishing application is installed and it can be logged in. Alternatively, the registration and pre-configuration of the user account would be done on behalf of the customer, after which the user account's email adddress would be replaced by the customer's email address.

1. registration of a user account to BunnyCDN
2. creation of a pull zone ID (see image 1)
3. adjusting other important pull zone settings (see image 2)
4. prepaying for the usage time (e.g. PayPal payment) after 14 days at the latest (the trial period of the BunnyCDN will then end)
5. setting the CDN address [1] in the settings of the publishing application, both at the managing interface and in user's settings

The pull zone term is explained in more detail in the BunnyCDN's instructions: https://support.bunny.net/hc/en-us/articles/207790269-How-to-create...

SSL certificate

When using a publishing application in a browser, the web address will start with either HTTPS or HTTP. First one of these mean that the connection from the user's browser to the servers used by the publishing application is secure, i.e. the traffic could not, according to general consensus, be intercepted and captured, e.g. on public WiFi networks. At least by monitoring the network, that is. The security of user devices is a separate issue. To protect the connection, an SSL certificate is needed, also known as Secure Sockets Layer (SSL) and Transport Layer Security (TLS).

Pricing: SSL certificates are priced on an annual basis, and it is not necessarily necessary to buy anything more feature-rich than PositiveSSL, which is available from many places (e.g. Namecheap) and with some luck for half the price from the same company from which you can buy a domain name. PositiveSSL costs less than 10 eur per year and is always purchased for a specific domain or subdomain and cannot be changed later. If you pay for five years at a time, the price would be around 5 eur per year. Once purchased, the certificate cannot be transferred from one vendor to another.

Notice: With a standard HTTP connection, all those connected to the same local area network may very well be able to capture the network traffic generated by others on that local area network using appropriate software (e.g. Wireshark), provided that no fancy security or encryption is in place. Or it could be that large organisation's such as an educational institution's network is used to log on to the publishing application or to read published works, in which case the ease with which users connected to that network can monitor each other's activity on that network depends largely on the competence of the IT department of that organisation. From outside the organisation, eavesdropping would be more difficult if it were not a wireless network, but on the other hand, when the browser and server parts of a publishing application communicate with each other, it is not really sufficient for the communication to be encrypted that the initial path, i.e. where the device used for browsing is physically located, is protected by an organisation, since there may be long physical and virtual distances from there to the server used by publishing application. In between, there are many different routing points and different parts of the network where data would travel unencrypted.

Deployment: SSL certificate deployment consists of a series of tasks that result in the final SSL certificate as a plaintext file to be copied to the server. The customer of the publishing application can perform all of the following steps, provided that the customer focuses on each of the steps with sufficient care. If the provider of the publishing application performs all the steps to deploy the SSL certificate, money would again have to be transferred as a PayPal payment and, finally, the customer might want to end up as the owner of the purchased SSL certificate, which requires a transfer of rights from one party to another. The purchase of an SSL certificate and all the steps involved are only necessary if the customer uses a different web address for the publishing application than one meant for testing purposes (defined on the first phases of becoming a customer).

1. registration to a marketplace (may be the same as when buying a domain name such as Namecheap)
2. purchase of an SSL certificate (the cheapest one, PositiveSSL, is sufficient)
3. starting the SSL certificate signing process by generating a CSR code (https://decoder.link/csr_generator)
4. copying the private key that gets generated at the same time (see image 1)
5. copying the CSR (Certificate Signing Request) code into the text field
6. select the Domain Control Validation (DCV) method (email validation must be chosen)
7. wait for a message to be received by email (see image 2)
8. click on the link in the validation message and enter the validation code when prompted (included in the same email)
9. wait for the second message to be received by email (see image 3)
10. extract the contents of the attached zip package from the email containing the SSL certificate to a directory (includes .crt and .ca-bundle files)
11. join the contents of the extracted files with the private key (create a new freely-named file with a .pem extension, containing first the contents of the .crt file, second the contents of the .ca-bundle file and third the private key)
12. send the .pem file to the publishing application provider

After step 9, you can send the emailed zip file to the publication application provider and skip the rest of the steps, but that alone is not enough, as the generated private key is still needed. The private key can be included directly in the email as text, as it is base64 encoded and cannot be distorted while the email travels over the internet.

For more information on the CSR code, see for example: https://www.namecheap.com/support/knowledgebase/article.aspx/337/67...

For more information on the DCV validation method, see for example: https://www.namecheap.com/support/knowledgebase/article.aspx/9637/6... (olennaisia ainoastaan alaotsikoiden "Receive an email" ja "Changing DCV methods" alla olevat tekstit ja kuvat)

Once the SSL certificate is finally installed, its functionality can be checked with any of the online certificate verification services.

--

VPN connection

If there is simply no motivation to fiddle with SSL certificate deployment, a user with a user account can at least to some extent hide from others the information about when, where and how the publishing application is used. For this purpose, a VPN (Virtual Private Network) connection, which can be easily purchased and installed for use with a wide range of devices and operating systems, can be used to protect all internet traffic from a device to the server acting as an intermediary, which then makes the actual connections to the servers of the publishing application. The second half of the VPN connection will not become encrypted on its own if the server is not set up to use it, i.e. if the server does not have an SSL certificate in place.

Pricing: Paid directly to the VPN service provider.

Notice: Some browsers used in some organisations may be configured to allow access only to sites that are accessed using the HTTPS protocol (e.g. https://example.com). HTTPS requires an SSL certificate, and in the absence of one from the server used by the publishing application, the user's browser may give a very visual indication that the web page being visited is not secure. In other words, the VPN would only benefit the authenticated user who is using the VPN connection.