Search, mail & access

By now your sites are up, deployed, and tuned. This topic is about the extras that sit around a running site — the services and switches you reach for now and then rather than every day:

• Search — giving a site a proper Solr-powered search backend instead of Drupal's built-in one.
• Access control — the built-in protections BOA turns on for you, and how to opt out of one when it's genuinely in your way.
• Browsing your database — looking directly at a site's tables in your browser when you need to check or fix a row by hand.
• Outbound mail — how the mail your sites send actually leaves the server, and what to do when a message doesn't arrive.
• New Relic monitoring — pointing your sites at a full application-performance dashboard when the built-in logs aren't enough.

None of this is something you have to set up before your sites work. Each one is here for the day you actually need it — so feel free to skim now and come back when a real task brings you here.

What's already done for you

The good news for a hosted account is that most of the heavy lifting lives on the server, and your host has already done it:

• The Solr search server (if your plan includes it) is installed and running. You don't start it, patch it, or manage its memory — you just point a site at it.
• The database browser (Adminer) is installed and served over HTTPS. You don't install it; you open it in a browser and log in with a site's own database credentials.
• The mail system (Postfix) is configured to carry your sites' outgoing mail. Your sites send with Drupal's normal mail tools and the server takes it from there.

Your part is small and always happens in your world — a setting in one of your INI files, a form in the web control panel, or a URL in your browser. Nothing here needs root, and nothing here touches anyone else's account.

A note on search

Turning on a Solr core is a two-part job, and it helps to know which part is yours:

1. The search module is yours. BOA does not add or configure a search module in your codebase — you install the one that suits your Drupal version (for example search_api_solr for Drupal 8+ or Drupal 7), add its dependencies, and enable it, exactly as you would on any Drupal site.
2. The Solr core is BOA's job. Once you set solr_integration_module in the site's INI file, BOA's search helper creates a dedicated Solr core for that site, applies the right schema.xml and solrconfig.xml, and hands you the connection details. Comment the line out again later and BOA cleanly removes the core for you a few minutes afterwards.

For Drupal 8 and newer the module generates its own core config files, which you place under the site's files/solr/ directory; BOA picks them up on its next few-minute pass. The step-by-step is in the Search (Solr) for your site page, and the full list of solr_* settings is on INI settings.

A note on your database browser

Adminer is a single-file database manager your host has already installed. You reach it in your browser at an address on your host's management hostname (your host will give you the exact URL), it's HTTPS-only, and access is limited to approved locations.

You log in with a site's own database credentials — the database name, username, and password BOA generated for that site and stored in its settings.php. That means each login only ever sees the one site's tables, never the whole server.

It's a sharp tool, so treat it like one:

• Back the site up first. A backup before any hand-edit means a bad change is a restore away, not a disaster.
• Read before you write. Browsing and exporting are safe; editing rows by hand can quietly break a site if you change something Drupal cares about.
• Prefer Drupal's own tools when they exist. For most jobs a Drush command or the site admin is safer than editing tables directly.

If you open the address and it won't load at all, that's usually because your current location isn't on the allow-list — one short support request asking your host to add your address sorts it out.

A note on the mail your sites send

Your sites send mail the ordinary Drupal way — a password reset, a contact-form message, an order confirmation. Behind the scenes BOA runs a mail system that picks that mail up and sends it on. You don't configure the server side of that, and there's nothing for you to install to make basic mail work.

What is on your side is everything inside Drupal: the site's email address and mail templates, and any contributed mail module (for example an SMTP or transactional-email module) you've chosen to route mail through.

When a message doesn't turn up, start there and check whether it landed in the recipient's spam folder — those are the common causes and they're all yours to fix.

Some delivery problems, though, are purely server-side and genuinely not something you can act on from your account — for instance:

• outgoing mail is being blocked at the network level,
• your host needs to set up or adjust a mail relay, or
• your sending domain needs SPF/DKIM/DMARC records that live in DNS you don't control.

If you've ruled out the Drupal side and mail still isn't arriving, that's the point to open a support request: say which site, roughly when, and to whom, and let your host check the delivery path. The Sending mail from your site page walks through the whole checklist in order.

A note on print & PDF tools

If a site of yours makes PDFs — a print module, printable invoices, an entity-to-PDF feature — the two heavy lifters those modules shell out to are already installed on every BOA server, at their standard paths:

• /usr/bin/wkhtmltopdf — renders a web page to PDF (its sibling /usr/bin/wkhtmltoimage, for page-to-image, is there too).
• /usr/bin/pdftk — merges, splits, and stamps PDF files.

So when a print/PDF module asks where its binary lives, point it at the system copy — for example /usr/bin/wkhtmltopdf — instead of uploading your own build into the platform or a library folder. The system copies are kept executable and current for you; a private copy inside your codebase is one more thing to maintain, and modules find the system path without any of that.

When it's not yours to do

A hosted account is deliberately kept away from the machine itself, so a few things in this topic are your host's to handle. When you hit one, don't go looking for a workaround from your shell — a single support request is the right move:

• Installing or resizing the Solr server, or adding a Solr core config file you can't generate yourself (the custom schema.xml / solrconfig.xml route).
• Getting your address onto the database-browser allow-list so Adminer will open for you.
• Anything in the mail delivery path — a blocked outgoing port, a mail relay, or DNS records for your sending domain.

In each case the fix is quick on their side; you just need to ask.

Where to go next

• Which of your files to edit for any of the INI settings mentioned here — and why a change takes about a minute to show up — is explained in Which file do I edit?.
• The full, per-line reference for the solr_* and access-control settings is on INI settings.
• Taking a backup before any hand-edit is covered in Backups.
• Getting into your oN.ftp shell, if a step here sends you there, is in Connecting to your account.
• The INI settings named across these topics are collected, alongside BOA's other documented configuration variables, in the shared Reference.