Michael restore Monica Cellio's questions

Forgive me if this question is answered elsewhere but most references to long lived AWS Lambda are about process runaway or something going wrong.

My question is: is Lambda (or whatever is Microsoft's equivalent) suitable for running processes that by design can run for up to half an hour? We have a set of PHP scripts that currently run as Webjobs on Azure. Some run for a few seconds every 5 or 15 minutes and some run once a month and take up to 30 minutes. I am looking at rewriting in Java/Kotlin and hosting on Lambda, but I have read that Lambda functions may not run for more than 30 seconds.

Supplementary: can Lambda handle automatically running these scripts according to a schedule that we specify?

There's a lot of opinion about storing BLOBs in a database and I wonder if there is any actual investigation or figures on the matter.

We have an application that stores images related to various entities such as user (their profile picture) and event (a photo of the event taking place). The application database table stores a file name such as 1234joesmith.png in a column called image and the our server-side code forms a complete URL from that to return to the front end, such https://ourapp.com/uploads/users/1234joesmith.png. (This is obviously a security risk and I will be dealing with that problem separately.)

This I am sure has been done to avoid placing BLOBs in the database and slowing-down access to it. However, it precludes an architecture where we have multiple server-side instances with a load-balancer or other redundancy middleware, all using the same database (which could then be an AWS database instance, for example).

My suspicion is that the advice to keep BLOBs out of the database is based on old technology and is obsolete. For example, a mysql table row is limited to a total of 4kb, but BLOBs and TEXTs do not count towards that total, except that each such column adds a fixed few bytes only. Clearly then the BLOBs and TEXTs are stored indirectly and not placed inline in the table row. Obviously therefore the designers of mysql have considered the matter of storing BLOBs and will have minimised any overhead, so that it is not significantly different from filesystem access (I suspect).

So my question: where are the figures, the actual figures? and not hand-wavy "I would have thought" speculations, which I can make as well as the next person.

This article implies that it's easy, but gives no details.

I have a double QLogic card in my OmniOS server, connected via two fibre-optic cables to SFP adaptors in my Procurve switch. What I would really like is to aggregate the two connections so I have one double-capacity IP connection between switch and server.

I've looked at cfinfo, cfadm, cfgadm, ipadm, dladm, luxadm, prtpicl and stmfadm but cannot see how to do it. There are many references to using fibre for storage, but none for IP.

I'm a developer more than a devops or sysadmin. person and I'm trying to work out what we have to do about SSL certificates and our AWS databases. It is well-known that the certificates issued in 2015 for AWS databases will expire on 5 March 2020 and it is necessary to install the certificates issued in 2019.

However, it seems to me that we don't need certificates to connect to our AWS database. What I mean by that is that to connect to one of our Azure databases, the following *nix command is required:

mysql -h ourstuff.database.azure.com -u ouruser -p --ssl-ca=certificatefile.crt.pem --ssl-mode=VERIFY_CA

but to connect to our AWS database, we don't need that SSL stuff:

mysql -h ourstuff.blahblahblah.rds.amazonaws.com --database=ourdatabase -u ouruser -p

Similarly, we have PHP applications that supply the certificate to connect to the Azure database (via mysqli_ssl_set()) but not for AWS.

So I have these questions:

• Since there is no option in the AWS dashboard for removing the certificate from the database, how is it that I can connect to the database without supplying any credentials? (other than a password) Is it because I am on a my company's network, and the network is whitelisted?
• What should I do to force clients to supply credentials? Empty the IP whitelist table? If a such thing exists.
• If access is based on IP whitelisting, would it really increase the security of the database if we mandated access via SSL?
• If a certificate isn't required now, owing to the connecting username (as per Mlu's answer below), will that change when I install the 2019 certificates?

Thanks in expectation.

I'm trying to configure https support for Apache2 running in an Ubuntu instance in AWS. I've enabled SSL support in /etc/apache2/sites-enabled/default-ssl.conf:

# grep -v '^[   ]*#' /etc/apache2/sites-enabled/default-ssl.conf | grep -v '^$'
<VirtualHost *:443>
    ServerName miit.co
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/miit_co.crt
    SSLCertificateKeyFile /etc/ssl/private/miit-co.key
    <FilesMatch "\.(cgi|shtml|phtml|php)$">
            SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
            SSLOptions +StdEnvVars
    </Directory>
</VirtualHost>

and the configuration as a whole is valid:

# apachectl configtest
Syntax OK

The file /etc/ssl/private/miit-co.key is a "PEM RSA private key" which I generated (can't remember how exactly now) and /etc/ssl/certs/miit_co.crt is one of two files I received back from my non-technical boss, the other being miit_co.pem which I don't know what do with. I also have a csr.pem (PEM certificate request) which I generated and sent to my boss. I did not send him the private key file. Maybe I have to do something with that miit_co.pem file.

When I start Apache (systemctl start apache2) there is nothing in /var/log/apache2/{error,access}.log to indicate that Apache2 is not running normally. However, https://www.digicert.com/help/ when given our site name (miit.co) just spins and spins. I wonder if there is something other than Apache stopping https access, since http://miit.co works as expected (it redirects in fact but that's not relevant here) but https://miit.co just times out. ufw status replies disabled.

/etc/apache2/mods-enabled includes ssl.{conf,load}.

If I try curl on the local machine, it indicates that Apache is being reached by https requests:

# curl https://localhost
curl: (51) SSL: certificate subject name (miit.co) does not match target host name 'localhost'
# curl https://miit.co/michael
(hangs)

Any suggestions as to why https: access just hangs?

I'd like to divert off requests to a particular sub-directory, to another root location. How? My existing block is:

server {
    listen       80;
    server_name  www.domain.com;

    location / {
        root   /home/me/Documents/site1;
        index  index.html;
    }

    location /petproject {
        root   /home/me/pet-Project/website;
        index  index.html;
        rewrite ^/petproject(.*)$ /$1;
    }

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    } }

That is, http://www.domain.com should serve /home/me/Documents/site1/index.html whereas http://www.domain.com/petproject should serve /home/me/pet-Project/website/index.html -- it seems that nginx re-runs all the rules after the replacement, and http://www.domain.com/petproject just serves /home/me/Documents/site1/index.html .

following-on from my earlier question about resurrecting an ancient Intergraph 6800 machine (licence file for extra logins on ancient Unix (CLIX) system), the original problem was a failed hard disk so This Must Not Happen Again. All the crucial data are on the separate /usr partition so I was wondering about making the file system more robust. On a modern system this would be trivial but on this ancient Unix it's something of a challenge.

One option would be mount /usr on a separate, modern machine with RAIDx but the NFS client software is a separate licensed option and I don't know if anyone can provide us with a a licence nowadays.

The CLIX software doesn't include any kind of meta-device software like Sun's md subsystem that lets you treat multiple raw devices as one.

So I wondered: is there anything like a SCSI-2 box that appears to be a single target but in fact contains redundant disks ?

Another option might be to compile an old version of the Samba client software on the machine but it's starting to get a bit tricky.

The fallback option is to pull the crucial data off via FTP from time to time but that's a bit low-tech and I suspect that the procedure to do so would be neglected.

I'm helping to sort out an ancient Intergraph 6800 machine at work, running CLIX, a proprietary Unix.

Binning the system is not an option. It is a certified safety-critical system that would cost $millions to replace. Please do not post suggestions that the system could be replaced as it is utterly infeasible to do so, even if the problem detailed in this posting cannot be addressed.

Recently the hard-disk died so (before I was involved) the OS (1999 vintage) was installed on a new hard disk. A recovery company got all the files off the old hard disk and most of my involvement has been copying applications and data off the CD supplied by the recovery company and setting ownership and permissions correctly on the fresh installation.

One point however is that the system used to allow at least six users to log in but now if more than two do, /bin/login says:

Too many users logged on.
Try again later.

Those strings are in the /bin/login executable.

The system does use a licencing system and I suspect that a crucial licencing file is missing from the fresh installation. I'm sure it will be on the recovery CD but does anyone with knowledge of these old licencing systems have any suggestions about where the files are so I can copy them across from the CD ?

PS, if anyone has a licence for Intergraph NFS that they want to liquidate, we might be interested.