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.

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.

In this topic

Search (Solr) for your site — switching a site from Drupal's basic search to a real Solr search core. You add a search integration module to your codebase, set one line (solr_integration_module) in the site's boa_site_control.ini, and BOA creates and wires up a private Solr core for that site within a few minutes — no waiting until the next day. When it's ready, BOA drops the connection details into a solr.php file inside the site's directory so you can point the module at the right core. The line reference for every Solr setting lives on the INI settings page; this page is the friendly walkthrough that ties it to your search module.
Restricting access to your site — the protections BOA switches on by default (a redirect that shields /admin* from being hammered, a spam-safe registration policy on Drupal 6/7 sites, and more), what each one does for you, and how to relax one from your site's boa_site_control.ini on the rare occasion it blocks something you actually need. The default in every case is the safe choice.
Browsing your database — opening the built-in Adminer database manager in your browser to look at, export, or carefully edit a site's tables. Covers where to find the address, how to log in with a site's own database name, user, and password (the ones BOA already put in the site's settings.php), and the safety habits worth keeping — take a backup first, and never touch tables you don't recognise.
Sending mail from your site — how the mail your sites send actually leaves the server, what to check on your side first when a message doesn't arrive (the site's own mail settings and templates, whether a contributed mail module is configured, whether messages are landing in spam), and how to tell a site-configuration problem you can fix from a server-delivery problem only your host can.

A note on search

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

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.
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 if outgoing mail is being blocked at the network level, or 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.

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.
Exact task names, form fields, and control-file names are collected in the shared Reference.