Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


apnscp 3.1 released! - Page 5
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

apnscp 3.1 released!

1235»

Comments

  • nemnem Member, Host Rep

    @hackerman said:
    This way I can push out an update across all domains, proactively protecting in the case of security vulnerabilities which is only becoming more common with WordPress plugins.

    This is the basic idea behind FLARE updates. You can alter the FLARE endpoint via apnscp_flare_endpoint in Bootstrapper. It'll use that configured endpoint so long as the certificate comes from the ApisCP CA and its common name matches the FLARE endpoint. If the timestamp is newer than last check, FLARE will force upcp. This process allows you to quickly inject additional platform migrations if you're delivering panel updates from a custom repo.

    That's the strategy I use with Hostineer. Those servers update from an internal repo that's a mixture of ApisCP and Hostineer code, so I can rollout code specific to Hostineer in addition to whatever's mainline in ApisCP.

    Migrations with admin:collect() work great for filtering/iterating over sites. Ansible's a fantastic utility to apply changes in a consistent, simplified, yet programmatic way. For example, CPU weights were zeroed to 100 in a migration only for sites that had the feature enabled. It's a good example of how to filter and work over sets of sites.

    If you're running your own repo, you could slip in a migration like that to apply to all matching sites whenever the need arises. wordpress:asset-summary() returns an array of all plugins/versions on a WP install if you wanted to examine specific assets or just run wordpress:update-all() to force a mass update ahead of schedule.

    Unfortunately they are discontinuing it due to stability concerns.

    Not selling me on adopting ARM :P

  • nemnem Member, Host Rep

    Summer has been busy with a ton of great new features since last update! v3.1.44 is out with a slew of cool new features.

    Vendor licensing is now available! Issuance follows a very simple REST API. Depending upon commit rates you can resell these licenses within your network a fraction of retail costs. Commit rates carry a minimum buy of 50 licenses per pak and contract duration of 12 months. Get in touch with [email protected] to get started.

    Service monitoring is now part of the admin frontend. Argos is a unified monitoring framework that monitors, remediates, and alerts through a variety of services (Slack, email, XMPP, etc). For example, I forward remarkable events to my phone via Pushover using Argos' relay service. All Argos features are now exposed through the "argos" module.
    Argos service monitoring

    Let's Encrypt issuance staging allows you to separately stage a challenge, then resume authorization.

    API hooks have been added, which unlike a surrogate, decouple implementation logic and cannot override module signatures. API hooks are called after an API method is invoked, which makes it simple to always add WordPress plugins after installation or dispatch additional notifications whenever a password is changed.

    Web App screenshots are generated for each site by default (unless has_low_memory is enabled). Screenshots provides quick recognition when working with aliased/stacked domains. Better yet, there's heavy lifting with unshare/bind mounts in the background to ensure screenshots only generate against sites on the server and not off-server if DNS isn't correct. This ameliorates some privacy concerns during screenshot generation. It's also possible to generate these as a oneshot using cpcmd web:inventory-capture and setting a very large [screenshots] => ttl value.

    Lastly, Update Assurance is here. Update Assurance is a precheck for Web App updates that generates a snapshot (database + filesystem), records HTTP status, and content length for each update. After that update completes, HTTP status and content length are re-evaluated. If HTTP status reports back 2xx and content length stays within a 5% range, the update is deemed successful otherwise ApisCP will automatically roll the update back and mark it failed. 5% is a general guideline, but may be adjusted under [webapps] => assurance_drift using the cp.config Scope in ApisCP.
    Update Assurance

    One of the biggest challenges in deploying automated updates, which are a necessary feature to maintain secure environments, is ensuring the process is reliable. Update Assurance adds a crucial secondary level of reliability. There's nothing more frustrating than getting a call at 8 AM in the morning because your site's displaying gobbledygook due to a botched update or worse, getting slapped with a red warning by Google for harboring malware.


    Next on the list, I'll begin opening up the Web App framework for third-party as well as basic Fortification profiles for custom sites as well as adding dynamic map support to rspamd. Part of spam handling UI has been rewritten in .44 with more due up in .45 and .46. Be on the lookout for a sale in July, Apis turns 18 years old then :)

Sign In or Register to comment.