Comprehensive Knowledge Base

A domain is your online identity (example.com). Consider brand fit, ease of spelling, shortness, and suitable TLDs. Important commercial rules:

• Prefer .com for international presence; use local ccTLDs for geo-targeting (.lt, .uk, .de).
• Use hyphens only if necessary; avoid long confusing strings.
• Register similar TLDs to avoid brand abuse (optional but recommended).

1. Search domain name using Lyvora domain tool. Consider alternative suggestions if your first choice is taken.
2. Choose registration length and privacy (WHOIS privacy hides your contact details from public WHOIS).
3. Complete checkout. The domain will appear in your Lyvora dashboard under Domains.
4. Set nameservers (use Lyvora nameservers if you want DNS management in cPanel, or set to Cloudflare/other if you want external DNS control).

1. Ensure domain is older than 60 days and not locked due to recent changes.
2. At current registrar: unlock domain and request EPP/Auth code; disable WHOIS privacy to receive transfer confirmation emails.
3. Initiate transfer in Lyvora → input EPP → approve transfer emails — finalization takes usually 2–7 days.
4. Keep a maintenance window and monitor email for any required approvals.

Key DNS records you will use often:

• A — map hostname to IPv4 (e.g., example.com A 198.51.100.23).
• AAAA — map to IPv6 (e.g., example.com AAAA 2001:db8::1).
• CNAME — alias to another hostname (e.g., www CNAME example.com), not allowed on zone root.
• MX — mail servers with priority (e.g., 10 mx1.mailprovider.com).
• TXT — arbitrary strings used for SPF, DKIM, verification (e.g., Google site verification).
• SRV — service records for SIP/XMPP (specify priority, weight, port and target).
• NS — authoritative nameservers for the domain. Changing NS delegates control of zone.

These three together vastly improve email trust and deliverability.

1. SPF: Add a TXT record, e.g.:

   v=spf1 a mx include:_spf.google.com ~all

   – use include for third-party senders and keep string length reasonable.
2. DKIM: Generate a DKIM key (cPanel or mail provider). Publish public key as TXT:

   default._domainkey.example.com v=DKIM1; k=rsa; p=PUBLICKEY

   Enable signing on your mail server.
3. DMARC: Start with monitoring:

   _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

   Move to quarantine and then reject as confidence increases.

TTL controls caching duration at resolvers. For migrations: lower TTL to 300 (5 min) a day before changes; after stable, increase to 3600–86400.

PTR maps IP → hostname and is used by many receiving MTAs to validate email source. PTR must be configured by the IP owner (your hosting provider or cloud provider). Ensure PTR matches the HELO/EHLO of your mail server for best deliverability.

1. Confirm authoritative nameservers with whois or online tools.
2. Query authoritative server with dig @ns1.provider example.com A.
3. Check for conflicting records (no CNAME at root, no duplicate NS records).
4. Validate SPF/DKIM results with tools like MXToolbox and DMARC analyzers.
5. For propagation issues use DNS Checker to view global resolution.

• Let’s Encrypt / AutoSSL (DV) — free, automatic, great for most websites; renews every 90 days automatically when enabled.
• Paid DV/OV/EV — extra validation and warranty; OV/EV often used for corporate or e-commerce sites requiring higher trust.
• Wildcard — single certificate for all subdomains (*.example.com).
• SAN / Multi-domain — secure multiple different domains on one certificate; useful for consolidated setups.

1. Login to cPanel → SSL/TLS Status → Click “Run AutoSSL”. AutoSSL will request and install certificates for eligible domains/subdomains automatically.
2. If AutoSSL fails for a subdomain, inspect the domain’s DNS and ensure HTTP verification works (port 80 should be reachable by Let’s Encrypt validation server).
3. After issuance, test HTTPS in browser and check cert path; use SSL Labs test for deep diagnostics.

1. Generate CSR in cPanel → SSL/TLS → Certificate Signing Requests (fill accurate org information).
2. Submit CSR to Certificate Authority, complete validation (email/file/DNS).
3. Install certificate and CA bundle via cPanel → SSL/TLS → Manage SSL Sites.
4. Force HTTPS via .htaccess or server-level redirect and check for mixed-content (use browser console to find non-HTTPS assets).

• Disable TLS 1.0/1.1, prefer TLS 1.2+ and TLS 1.3 where supported.
• Configure strong ciphers; prefer ECDHE suites and avoid RC4, DES.
• Enable HSTS carefully (test with max-age=3600 before long durations); includeSubDomains only when certain.
• Enable OCSP stapling to serve certificate status quickly.
• Use secure cookie flags (Secure, HttpOnly, SameSite).

WAFs (ModSecurity, Cloudflare, Sucuri) protect against common web threats (SQLi, XSS, etc.). Use managed WAF or a CDN with WAF rules for best defense. For DDoS, employ CDN/edge scrubbing services with anycast and rate limiting.

• Enable 2FA for cPanel, WHM, and any admin panels.
• Use SSH public-key auth on servers; disable password auth if possible.
• Implement role-based accounts in team environments and rotate credentials regularly.

1. Take compromised VM/site offline or put behind maintenance/deny rules.
2. Collect logs and forensic snapshots (disk image, DB exports) before making changes.
3. Identify entry vector, remove malicious files/backdoors, change all admin passwords and rotate keys.
4. Restore from known-good backups and patch the vulnerability; inform stakeholders per legal/regulatory obligations.

1. cPanel → Softaculous Apps Installer → WordPress → Install.
2. Choose installation domain and directory, admin username (avoid ‘admin’), and a strong password; fill site name and description.
3. Finish installation and login at /wp-admin. Immediately install security plugin and backup solution.

1. Download WordPress from wordpress.org and upload to server.
2. Create MySQL DB and user via cPanel and grant privileges.
3. Set up wp-config.php with DB credentials and unique salts (use WordPress secret-key generator).
4. Complete web-based setup and configure permalinks and basic settings.

Choose plugin-based for simplicity; manual approach for max control.

1. Plugin path: All-in-One WP Migration / Duplicator → export full package → import on new host → update permalinks and reissue SSL.
2. Manual path: Export DB via phpMyAdmin, copy wp-content, upload to new host, import DB, update wp-config and run search-replace for old->new domain (use WP-CLI or interconnect/it tool).
3. Test media, links, and scheduled tasks (cron); if using scheduled tasks, configure alternative cron execution (WP-Cron via real cron) for reliability.

1. Install WooCommerce plugin and run the setup wizard (store address, currency, product types).
2. Configure tax rules and shipping classes (use zones for per-country rules).
3. Setup payment gateway(s): Stripe, PayPal — ensure webhooks configured and tested in sandbox first.
4. Configure product data: SKUs, stock management, variations, downloadable product settings, and image sizes.
5. Protect checkout with HTTPS, implement cart/checkout caching exemptions where necessary, and minimize cart fragments that can cause extra queries.

• Restrict wp-admin by IP or add 2FA for admin accounts.
• Keep core/plugins/themes updated; use staging to test updates.
• Limit plugin count; remove unused plugins/themes.
• Schedule daily backups for stores and keep backups offsite).

• Use server-level caching and an optimized cache plugin; test cache behavior carefully for dynamic checkout pages.
• Enable object cache (Redis) to reduce DB load for high-traffic stores.
• Offload media to CDN or object storage; serve images as WebP and use lazy loading.
• Monitor slow query logs and add indexes where necessary to heavy WC tables (wc_order_items etc.).

Large stores often separate web & DB tiers (managed DB like RDS or MySQL cluster), use read-replicas, and offload sessions/carts to Redis. Employ horizontal scaling with a load balancer and sticky sessions or shared session store.

1. cPanel → Email Accounts → Create: enter local part (e.g., info) and choose domain, set a strong password and quota.
2. Use forwarders for role addresses (sales@ → owner@) and set autoresponders where appropriate.
3. Delete or archive unused accounts to reduce attack surface and licensing costs.

IMAP is recommended for multi-device sync. POP3 is legacy and downloads mail. Exchange or hosted Microsoft 365 provides calendaring and contact sync—useful for organizations requiring shared calendars.

Outlook (Windows / Mac)

1. File → Add Account → Manual Setup → POP/IMAP.
2. Incoming (IMAP): mail.yourdomain.com Port 993 (SSL/TLS). Username = full email address.
3. Outgoing (SMTP): mail.yourdomain.com Port 587 (STARTTLS) or 465 (SSL). Enable SMTP auth.
4. For Exchange/Hosted, use Exchange connector and auto-discovery if available.

Gmail web (send-as) & import

1. Gmail Settings → Accounts & Import → Add a mail account → follow steps for POP3 import or SMTP send-as configuration.
2. Configure SMTP with mail.yourdomain.com and proper port/credentials so Gmail can send as your domain.

iOS Mail / Android Gmail app

1. Add account → Other → Add Mail Account (iOS) or Other (Android) → enter full email and password.
2. Set IMAP (recommended) with incoming server mail.yourdomain.com, port 993 SSL; SMTP port 587 STARTTLS.

1. SPF: Publish a TXT record like:

   v=spf1 a mx include:_spf.yourprovider.com ~all

   Use ~all for soft fail during setup; move to -all when confident.
2. DKIM: Generate key on mail server or via provider; publish public key under default._domainkey. Enable signing on mail server.
3. DMARC: Start with monitor mode:

   _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; pct=100"

   Transition to quarantine then reject based on reports.

• Check logs for bounce codes: 5xx = permanent, 4xx = temporary. 550 often indicates blocked or IP blacklisted.
• Use tools: MXToolbox, Mail-Tester.com, and Google Postmaster Tools to assess reputation and authentication.
• Warm-up new IPs: start with small volumes and gradually increase to build reputation.
• Avoid content triggers: too many images, spam phrases, and poor HTML structure can trigger filters.

1. Prefer transactional/Bulk ESPs (SendGrid, Mailgun, Amazon SES) for high volume instead of host SMTP.
2. Segment your audience, implement suppression lists and unsubscribes, and monitor complaint/bounce rates.
3. Authenticate and set reverse DNS for sending IPs used by ESPs or your own server.

• Define RPO and RTO for each application (how much loss acceptable and how quickly recovery must occur).
• 3-2-1 rule: 3 copies, 2 different media, 1 offsite.
• Consider encryption for backups at rest and in transit.

1. cPanel → Backups → Download a Full Account Backup. Choose destination: home directory or remote FTP.
2. When complete, download to local storage or push to cloud (S3/B2) for long-term retention.
3. Verify archive integrity by extracting in a test environment.

1. phpMyAdmin: Export → Quick/Custom → SQL. For large DBs use compression and chunking.
2. SSH:

   mysqldump -u dbuser -p dbname | gzip > dbname.sql.gz

3. For extremely large DBs use Percona Xtrabackup or managed DB snapshots for zero lock backups.

Use host-managed daily snapshots where available; otherwise schedule scripts that create dumps and push to remote (s3cmd/rclone). Retention strategy example: daily x7, weekly x4, monthly x6.

1. File restore: upload and extract archive to appropriate path; set ownership/permissions.
2. DB restore: create DB & user → import SQL via phpMyAdmin or CLI: mysql -u user -p dbname < backup.sql.
3. Full account restore: contact Lyvora support or use WHM (root) restore from backup if you have root access.

1. Pre-migration: provision target hosting, set PHP/DB versions to match source, enable staging SSL, create DBs and users.
2. Initial copy: transfer full files + DB to target and configure app (wp-config.php, env variables).
3. Testing: adjust hosts file locally to test the new host before DNS change. Check email, cron jobs, and background workers.
4. Sync: when ready, perform incremental sync (rsync for files, mysqldump for DB deltas) to minimize divergence.
5. Cutover: reduce DNS TTL in advance; at cutover update A record to new IP. Monitor logs and verify services (emails, SSL).
6. Rollback plan: keep old host for a short window and have DNS TTL rollback plan if critical issues appear.

• Mismatch in PHP extensions or versions — verify phpinfo().
• Hardcoded URLs in DB or config — run search-replace carefully, especially serialized data (use WP-CLI for WordPress).
• Missed cron jobs or scheduled tasks — re-create them on the target host.