Most Frequently asked Interview Questions of apache

Question: What are Apache modules and how do you enable or disable them?

Answer:

Apache modules are pieces of software that extend the functionality of the Apache HTTP Server. Apache uses a modular architecture, meaning that additional features or behaviors (such as security enhancements, SSL support, URL rewriting, or custom logging formats) are provided by loading specific modules. These modules can be dynamically loaded or unloaded based on your needs, which makes Apache highly flexible and customizable.

There are two main types of Apache modules:

1. Static Modules: Compiled directly into the Apache server during its build. These modules are always loaded when Apache starts and cannot be disabled without recompiling Apache.
2. Dynamic Modules: Loaded at runtime, these modules can be enabled or disabled without restarting or recompiling Apache, making them easier to manage.

Common Apache Modules:

• mod_rewrite: A powerful module that allows for URL rewriting and redirects based on regular expressions.
• mod_ssl: Enables SSL/TLS support for secure HTTPS communication.
• mod_headers: Allows manipulation of HTTP request and response headers.
• mod_proxy: Used for implementing proxy servers, including reverse proxies.
• mod_security: Provides security features, such as filtering HTTP requests to prevent attacks.
• mod_php: Enables PHP support in Apache, allowing the server to process PHP scripts.
• mod_deflate: Compresses content before sending it to clients to reduce bandwidth usage.
• mod_cache: Caching for improved performance.

---

Enabling and Disabling Apache Modules

On Debian/Ubuntu-based systems, Apache modules are typically managed using commands like a2enmod and a2dismod. On Red Hat/CentOS or other systems, modules are usually enabled or disabled by editing the Apache configuration files directly.

For Debian/Ubuntu-based Systems:

1. Enabling a Module

To enable a module, use the a2enmod command followed by the module name. This command creates a symlink in the sites-enabled or mods-enabled directories (depending on the module) to the actual module file in the sites-available or mods-available directory.

Example:

sudo a2enmod rewrite

This enables the mod_rewrite module, which allows you to use URL rewriting features.

After enabling a module, restart Apache to apply the changes:

sudo systemctl restart apache2

2. Disabling a Module

To disable a module, use the a2dismod command followed by the module name. This will remove the symlink from the mods-enabled directory.

Example:

sudo a2dismod rewrite

This disables the mod_rewrite module.

Again, restart Apache for the changes to take effect:

sudo systemctl restart apache2

3. List Enabled Modules

You can check which modules are currently enabled using the apache2ctl command:

apache2ctl -M

This will list all the modules currently loaded by Apache.

---

For Red Hat/CentOS-based Systems:

On Red Hat-based systems (like CentOS, RHEL, Fedora), Apache modules are loaded or unloaded by editing the Apache configuration files manually, typically located in the /etc/httpd directory.

1. Enabling a Module

In Red Hat-based systems, modules are generally enabled by uncommenting the appropriate LoadModule directive in the httpd.conf file or by adding the directive if it doesn’t exist. You can load a module by adding the following line to the configuration file:

Example for enabling mod_rewrite:

LoadModule rewrite_module modules/mod_rewrite.so

After editing the configuration, restart Apache:

sudo systemctl restart httpd

2. Disabling a Module

To disable a module, you simply comment out the LoadModule directive in the httpd.conf or relevant configuration file. For example, to disable mod_rewrite, comment out the line:

# LoadModule rewrite_module modules/mod_rewrite.so

After making changes, restart Apache:

sudo systemctl restart httpd

---

Checking Loaded Modules

On Debian/Ubuntu-based systems:

To check which modules are currently loaded in Apache:

apache2ctl -M

On Red Hat/CentOS-based systems:

Similarly, you can use:

httpd -M

This will list all modules currently enabled in Apache.

---

Manually Loading Modules

In some cases, you may want to load a module manually. You can do this by adding the appropriate LoadModule directive to the Apache configuration files, such as httpd.conf or specific module configuration files in /etc/apache2/mods-available/.

For example, to load mod_php, you would add:

LoadModule php7_module modules/libphp7.so

Then restart Apache:

sudo systemctl restart apache2

---

Example: Enabling mod_rewrite on Ubuntu/Debian

Here’s a detailed example for enabling mod_rewrite:

1. Enable the module:

   sudo a2enmod rewrite

2. Ensure that the AllowOverride directive is set correctly: In the Apache configuration, you need to allow .htaccess files to override settings. This is usually done by setting AllowOverride All in the <Directory> block.

   Example:

   <Directory /var/www/html>
     AllowOverride All
     Options Indexes FollowSymLinks
     Require all granted
   </Directory>

3. Restart Apache:

   sudo systemctl restart apache2

---

Conclusion:

Apache modules are essential components that extend Apache’s functionality. They are typically managed via commands like a2enmod and a2dismod on Debian/Ubuntu systems, while on Red Hat/CentOS, they are controlled by directly editing the configuration files. Enabling or disabling modules allows you to customize the behavior of your Apache server without needing to recompile the software, making it highly flexible for different use cases. After enabling or disabling modules, you must restart Apache for the changes to take effect.

Question: How does Apache handle URL rewriting with mod_rewrite?

Answer:

Apache handles URL rewriting using the mod_rewrite module, which is one of the most powerful and flexible tools for manipulating URLs. The module enables you to perform complex URL manipulations based on regular expressions and conditions, such as redirecting URLs, blocking or allowing access, and rewriting URLs for clean or SEO-friendly URLs.

The mod_rewrite module allows for dynamic URL rewriting, meaning URLs can be rewritten or redirected based on patterns or conditions set by the server administrator, and this process happens before the URL reaches the application (such as PHP, a framework, or static HTML files).

Key Concepts in mod_rewrite

• RewriteRule: This is the directive used to specify the pattern and replacement for the URL. It defines how to rewrite the URL.
• RewriteCond: This directive is used to specify conditions under which the rewrite rule will be applied.
• Regular Expressions: mod_rewrite relies heavily on regular expressions for pattern matching.

---

1. Enabling mod_rewrite

On most systems, mod_rewrite is already enabled by default. However, if it is not enabled, you can enable it by using the following command (on Debian/Ubuntu-based systems):

sudo a2enmod rewrite

Then, restart Apache to apply the changes:

sudo systemctl restart apache2

---

2. Basic Structure of mod_rewrite

The basic syntax for mod_rewrite is:

RewriteEngine On
RewriteRule pattern substitution [flags]

• RewriteEngine On: This enables the rewrite engine. It must be set to On to activate URL rewriting.
• RewriteRule: This directive defines the pattern that will match the requested URL and how it should be rewritten.

Example:

RewriteEngine On
RewriteRule ^oldpage$ newpage [R=301,L]

In this example:

• ^oldpage$ is the regular expression pattern that matches the URL path oldpage.
• newpage is the new path to which oldpage will be redirected.
• [R=301,L] are flags (explained later), indicating a permanent redirect (301) and that this should be the last rule processed (L).

---

3. Common Rewrite Flags

Flags can be added at the end of a rewrite rule to control the behavior of the rewrite. Common flags include:

• [R]: Redirect the client to the new URL. By default, it performs a temporary redirect (302), but you can specify other redirect types like 301 (permanent) or 303.

  • Example: [R=301] for a permanent redirect.

• [L]: Marks this rule as the “last” rule to be processed. If this flag is set, Apache stops processing further rewrite rules for that request.

• [QSA]: Appends the original query string to the rewritten URL.

• [NC]: Makes the match case-insensitive.

• [P]: Forces Apache to proxy the request to another server. Useful for reverse proxy configurations.

• [L,R=301]: Perform a permanent redirect and stop processing further rules.

• [F]: Forbids access to the requested URL (gives a 403 Forbidden response).

---

4. Example: URL Rewriting

Basic Example: Redirecting URLs

Here is an example where we redirect requests for oldpage to newpage:

RewriteEngine On
RewriteRule ^oldpage$ /newpage [R=301,L]

This redirects requests for http://example.com/oldpage to http://example.com/newpage using a 301 permanent redirect.

Example: Rewriting URLs for SEO-Friendly URLs

In many content management systems (CMS) or web applications, you might want to rewrite URLs to make them more readable or SEO-friendly.

For example, instead of accessing a URL like http://example.com/index.php?id=123, you might want the URL to appear as http://example.com/product/123.

You can accomplish this with the following mod_rewrite rule:

RewriteEngine On
RewriteRule ^product/([0-9]+)$ /index.php?id=$1 [L,QSA]

This rule:

• Matches URLs of the form product/123, where 123 is a number.
• Rewrites it internally to index.php?id=123.
• The [L] flag ensures this is the last rule processed, and the [QSA] flag ensures that any existing query string is appended to the new URL.

---

5. Using RewriteCond (Rewrite Conditions)

You can use RewriteCond to add conditions to your RewriteRule. These conditions specify when a rule should apply.

For example, you may want to redirect requests to http://example.com/oldpage only if the user is visiting from a specific domain:

RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://example.com
RewriteRule ^oldpage$ /newpage [R=301,L]

In this example:

• RewriteCond %{HTTP_REFERER} ^http://example.com specifies that the rule only applies if the request is coming from http://example.com.
• The RewriteRule then redirects to /newpage.

---

6. Common Use Cases for mod_rewrite

Redirecting Non-www to www

To redirect a domain from example.com to www.example.com:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]

Redirecting HTTP to HTTPS

To force all traffic to HTTPS, you can use this rule:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Preventing Access to Specific Files or Directories

To block access to certain sensitive files (e.g., .htaccess, .git directories):

RewriteEngine On
RewriteRule ^\.git/ - [F,L]
RewriteRule ^\.htaccess$ - [F,L]

• [F]: Forbids access by returning a 403 Forbidden status.

---

7. Debugging mod_rewrite

If you’re having trouble with mod_rewrite, you can enable debugging to see detailed rewrite logs.

1. Enable rewrite log by adding the following to your Apache configuration (usually httpd.conf or apache2.conf):

LogLevel alert rewrite:trace6

2. Restart Apache:

sudo systemctl restart apache2

This will provide detailed log information in the Apache error log, which is helpful for debugging rewrite rules.

---

Conclusion:

mod_rewrite is a powerful and flexible module in Apache for URL rewriting. It allows administrators to create SEO-friendly URLs, redirect traffic, block or allow certain requests, and manipulate URLs based on conditions. The key components of mod_rewrite are RewriteRule (for defining URL patterns and substitutions) and RewriteCond (for setting conditions for applying rules). By mastering regular expressions and rewrite flags, you can control how Apache handles incoming requests to your server.

Question: What is the difference between Apache and Nginx?

Answer:

Apache and Nginx are two of the most widely used web servers today, but they have different architectures and strengths. Both can serve web pages, handle HTTP requests, and support multiple modules for extending functionality. However, they are optimized for different use cases and perform in distinct ways. Here’s a comparison of the two:

---

1. Architecture

Apache:

• Process-based Model: Apache uses a process- or thread-based architecture, meaning each request is handled by a separate process or thread. This means that Apache can handle each connection individually, which allows for flexibility in configuration and module use.
• Multi-processing Modules (MPM): Apache supports multiple multi-processing modules (MPMs), which determine how the server handles incoming requests (e.g., mpm_prefork, mpm_worker, mpm_event). Each MPM has its advantages and disadvantages, depending on the server’s workload.

Nginx:

• Event-driven, Asynchronous Model: Nginx uses a single-threaded, event-driven model, where multiple requests are handled by a small number of worker processes. This approach is highly efficient because it allows Nginx to handle many concurrent connections with minimal resource usage. It’s especially well-suited for handling a large number of simultaneous connections (such as in high-traffic websites).

---

2. Performance and Scalability

Apache:

• Higher Resource Consumption: Apache’s process- or thread-based model can be more resource-intensive when handling a large number of simultaneous requests because each request consumes its own memory and CPU resources. As a result, it can struggle with scalability under heavy load, especially with many concurrent connections.
• Better for Dynamic Content: Apache’s modular architecture makes it a strong choice for serving dynamic content (e.g., PHP, Python, or Perl scripts) due to its support for various processing modules.

Nginx:

• Low Resource Consumption: Nginx’s event-driven architecture allows it to handle a large number of concurrent requests efficiently, even under heavy load. It is more lightweight in terms of memory and CPU usage, which makes it highly scalable.
• Better for Static Content: Nginx is particularly good at serving static content (e.g., images, CSS, JavaScript) quickly and with low overhead. Its architecture makes it ideal for applications that serve large amounts of static data or need to handle many simultaneous connections.

---

3. Handling Static and Dynamic Content

Apache:

• Dynamic Content: Apache can process dynamic content with ease by directly integrating with various programming languages like PHP, Python, and Ruby. This makes Apache a preferred choice for applications that require dynamic content generation (e.g., WordPress, Drupal).
• Static Content: Apache can serve static files but is not as efficient as Nginx when it comes to serving static content due to its process-based architecture.

Nginx:

• Static Content: Nginx excels at serving static content quickly, as it can serve static files directly from disk without involving any processing overhead.
• Dynamic Content: Nginx itself does not have the ability to process dynamic content directly. Instead, it works as a reverse proxy, forwarding dynamic requests to other back-end servers (such as Apache, PHP-FPM, or application servers like Node.js) for processing. This allows Nginx to act as a highly efficient front-end server, handling incoming traffic and forwarding requests for dynamic content.

---

4. Load Balancing

Apache:

• Basic Load Balancing: Apache can handle basic load balancing using modules like mod_proxy_balancer. While it works well for smaller or simpler environments, Apache’s thread/process-based model can limit its efficiency in high-traffic scenarios.

Nginx:

• Advanced Load Balancing: Nginx is widely known for its advanced load balancing capabilities. It can efficiently distribute traffic to backend servers using several algorithms such as round-robin, least connections, and IP hash. Nginx is also better at handling large-scale load balancing, especially for high-traffic websites.

---

5. Reverse Proxy and Caching

Apache:

• Reverse Proxy: Apache can function as a reverse proxy, forwarding requests to backend servers. However, due to its process-based nature, Apache’s reverse proxy capabilities are typically not as fast or scalable as Nginx’s.
• Caching: Apache supports caching with modules like mod_cache, mod_file_cache, and mod_mem_cache, but Nginx generally performs better in caching static content due to its lightweight, event-driven model.

Nginx:

• Reverse Proxy: Nginx is often used as a reverse proxy in front of application servers or web servers like Apache, to handle incoming requests, distribute traffic, and manage load. It’s especially useful in microservice architectures.
• Caching: Nginx excels in caching static content. It can cache responses from backend servers to serve them faster to clients, reducing load on backend systems and improving performance.

---

6. Flexibility and Configurability

Apache:

• Highly Configurable: Apache provides extensive flexibility through its configuration files, such as httpd.conf, .htaccess, and various modules. This allows administrators to fine-tune their web server to meet specific requirements.
• .htaccess: Apache supports .htaccess files, which allow for per-directory configuration, making it very flexible for shared hosting environments where users may not have direct access to the main configuration files.

Nginx:

• Simpler Configuration: Nginx has a simpler, more straightforward configuration syntax compared to Apache. However, it is not as flexible as Apache when it comes to per-directory configuration. Nginx configurations are typically managed in a centralized nginx.conf file.
• No .htaccess Equivalent: Nginx does not support .htaccess files. All configuration must be done centrally in the nginx.conf, which can be a disadvantage in shared hosting environments where users need to modify their server configurations independently.

---

7. Security

Apache:

• Security Modules: Apache has a wide range of security modules, such as mod_security, mod_ssl (for SSL/TLS), and others, allowing you to configure various security rules and protections for your server.
• Granular Control: Apache provides granular control over security policies, especially with .htaccess files, which can be used for authentication, access control, and more.

Nginx:

• Security: Nginx is considered to be more secure by default due to its smaller attack surface. It has a minimalistic design, meaning fewer opportunities for security vulnerabilities. It also supports SSL/TLS (via ngx_http_ssl_module) and is often used to handle SSL termination in front of application servers.
• Fewer Security Features: While Nginx is secure, it doesn’t have as many built-in security modules as Apache. However, its lightweight, single-threaded design helps reduce the complexity of security vulnerabilities.

---

8. Community and Support

Apache:

• Mature Community: Apache has been around since 1995, making it one of the oldest and most mature web servers. It has a large community and extensive documentation, which provides a wealth of resources for troubleshooting and configuration.

Nginx:

• Growing Community: Nginx is relatively newer (released in 2004), but it has gained a lot of popularity due to its performance advantages, especially in modern, cloud-based environments. Nginx also has excellent documentation, and there is a strong community, especially for users who need to implement high-performance web architectures.

---

9. Use Cases

Apache:

• Ideal for: Complex, highly dynamic applications (e.g., WordPress, Drupal), where fine-tuned configuration and extensive module support are needed.
• Best Use Case: Websites or applications that rely on a lot of dynamic content generation and need flexibility in terms of configuration.

Nginx:

• Ideal for: High-performance, high-traffic sites, and applications that serve static content or require efficient load balancing, reverse proxying, and SSL termination.
• Best Use Case: Websites or services that need to scale efficiently, handle many concurrent connections, and focus on performance, particularly for static content.

---

Summary of Key Differences:

Feature	Apache	Nginx
Architecture	Process-based	Event-driven, asynchronous
Performance	Higher resource usage	Low resource usage, scalable
Content Handling	Good for dynamic content	Excellent for static content
Load Balancing	Basic	Advanced, more scalable
Reverse Proxy	Possible but less efficient	Optimized reverse proxy functionality
Caching	Supports caching, but less efficient	Excellent caching of static content
Configuration	Flexible, with .htaccess support	Simpler, centralized configuration
Security	More extensive security modules	Minimalist but secure by default

---

Conclusion:

Both Apache and Nginx are highly capable web servers, but they shine in different areas. Apache is highly flexible and ideal for serving dynamic content, with rich module support and extensive configuration options. On the other hand, Nginx is optimized for performance and scalability,

making it a great choice for handling high-traffic websites or serving static content. Many organizations use both in combination, with Nginx as a reverse proxy and Apache serving dynamic content, taking advantage of the strengths of both web servers.

Question: What are the common performance tuning strategies for Apache?

Answer:

Performance tuning in Apache involves optimizing the web server’s settings to improve its speed, reduce resource consumption, and handle more concurrent connections efficiently. Below are some of the most common strategies for tuning Apache’s performance:

---

1. Optimize Multi-Processing Modules (MPM)

Apache uses different Multi-Processing Modules (MPM) to determine how it handles connections. Choosing the right MPM is crucial for performance.

• mpm_prefork: This is the default MPM for Apache. It creates a new process for each incoming request. It works well for compatibility with older applications (e.g., PHP), but it is not the most efficient for high-traffic websites due to its high memory usage.

• mpm_worker: This MPM uses multiple threads per process. It is more memory efficient and performs better under heavy load than mpm_prefork. It is well-suited for high-concurrency applications that use non-thread-safe modules.

• mpm_event: This is an advanced MPM designed to handle asynchronous connections. It is the most efficient and is recommended for modern workloads, especially if your Apache server is handling many concurrent requests (e.g., static content or using reverse proxying).

Action: In your httpd.conf or Apache configuration file, choose the appropriate MPM for your system and workload. You can enable an MPM like this:

LoadModule mpm_event_module modules/mod_mpm_event.so

---

2. Adjust KeepAlive Settings

KeepAlive allows the same TCP connection to be used for multiple HTTP requests, which reduces the overhead of setting up new connections.

• KeepAlive: Set this to On to enable persistent connections.
• KeepAliveTimeout: The default is typically 5 seconds. Reducing this value can improve performance, but it should be set high enough to avoid interrupting slow clients.
• MaxKeepAliveRequests: This limits the number of requests a single persistent connection can handle. Setting this to a lower value can reduce resource usage.

Example configuration:

KeepAlive On
KeepAliveTimeout 2
MaxKeepAliveRequests 100

---

3. Use Compression (mod_deflate)

Compressing content before serving it to clients can drastically reduce the size of responses, leading to faster load times and reduced bandwidth usage.

• Enable mod_deflate to compress common text-based content (HTML, CSS, JavaScript, JSON, etc.).

Example configuration:

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/x-javascript application/javascript application/json
</IfModule>

---

4. Optimize Caching (mod_cache, mod_file_cache)

Caching static content or dynamic content that doesn’t change often can reduce the server’s workload and improve performance.

• mod_cache: Use for caching dynamic content.
• mod_file_cache: Use for caching static files in memory.
• mod_expires: Control the expiration of cached content.

Example configuration for caching:

<IfModule mod_cache.c>
    CacheEnable disk /images
    CacheRoot /var/cache/apache2/mod_cache
</IfModule>

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresDefault "access plus 1 day"
</IfModule>

---

5. Use Content Delivery Networks (CDN)

If your website serves static content (images, stylesheets, JavaScript files, etc.), consider offloading this content to a Content Delivery Network (CDN). This can greatly reduce the load on your Apache server and improve the loading speed for users by serving static content from geographically distributed servers.

Action: Set up your CDN provider to serve static content, and use redirects or direct URLs to offload static assets from Apache.

---

6. Enable HTTP/2

HTTP/2 is a major improvement over HTTP/1.1, offering features like multiplexing, header compression, and server push to reduce latency and improve performance.

• To enable HTTP/2, you need to make sure you’re using SSL (mod_ssl), as HTTP/2 requires it.
• Use the mod_http2 module.

Example configuration to enable HTTP/2:

LoadModule http2_module modules/mod_http2.so
Protocols h2 http/1.1

---

7. Tune File Descriptors and Limits

Apache relies on file descriptors to manage incoming connections. If your server is under heavy load, you may need to adjust the limits for open file descriptors to ensure Apache can handle many concurrent connections.

• MaxClients/MaxRequestWorkers: Set this directive to control how many concurrent connections Apache can handle. For mpm_worker or mpm_event, increase the MaxRequestWorkers to handle more simultaneous requests.
• ServerLimit: In the mpm_prefork module, this defines the maximum number of processes.

Example configuration:

<IfModule mpm_worker_module>
    StartServers          4
    MinSpareThreads       25
    MaxSpareThreads       75
    ThreadLimit           64
    ThreadsPerChild       25
    MaxRequestWorkers     150
</IfModule>

---

8. Minimize the Use of .htaccess

While .htaccess files are convenient for making changes without restarting the server, they can introduce performance overhead because Apache needs to read them for every request.

Action: If possible, move configurations from .htaccess files to the main Apache configuration files (e.g., httpd.conf) and avoid unnecessary .htaccess directives.

---

9. Enable Connection Pooling for Database Connections

If your Apache server interacts with a database, connection pooling can significantly reduce the time and resources spent establishing connections for each request. This is especially useful for applications like PHP or other dynamic content.

Action: Use tools like mod_dbd (Apache database driver) for connection pooling or configure your application’s database library for pooling.

---

10. Profile and Monitor Apache Performance

Regular monitoring can help identify performance bottlenecks. Tools like mod_status, ApacheBench, and New Relic can help you gather real-time performance metrics.

• mod_status provides a live status page showing server activity.
• ApacheBench (ab) is a command-line tool for benchmarking the performance of Apache servers.

Example to enable mod_status:

<IfModule mod_status.c>
    ExtendedStatus On
    <Location "/server-status">
        SetHandler server-status
        Require host example.com
    </Location>
</IfModule>

---

11. Use the Latest Version of Apache

Always ensure you are using the most recent stable version of Apache. Newer versions include optimizations and security improvements that can enhance performance.

Action: Regularly update Apache and its modules to ensure you’re taking advantage of the latest improvements and bug fixes.

---

12. Enable SSL Optimization

SSL/TLS encryption adds overhead to Apache’s operations. However, there are ways to optimize SSL performance.

• Use Session Caching to reduce the overhead of establishing new SSL connections.
• Disable weak ciphers and protocols to improve security and speed.
• Use OCSP Stapling to offload certificate status checking.

Example:

SSLSessionCache shmcb:/var/run/ssl_scache(512000)
SSLSessionCacheTimeout 300

---

Conclusion:

Performance tuning in Apache requires a holistic approach, considering factors like connection handling, caching, compression, database optimization, and proper configuration. By applying these strategies, you can improve Apache’s ability to handle high-traffic sites, optimize resource usage, and reduce response times. Regular monitoring and updates are also crucial to ensure your server is performing optimally.

Read More

If you can’t get enough from this article, Aihirely has plenty more related information, such as apache interview questions, apache interview experiences, and details about various apache job positions. Click here to check it out.